Mitsules, Mark S. (Newport News)
Mark.Mitsules at ngc.com
Mon Dec 1 17:16:11 CST 2003
Andrew,
> If you're working in an intranet you can use integrated authentication.
I am developing for an intranet, but unfortunately, I stand little chance of
changing any IIS settings.
> If you're using .Net you can use impersonation
I'm a little familiar with WMI scripting and impersonation, but that
requires that you have administrator privs on the remote machine. Is this
similar to what you mention in .Net?
Mark
-----Original Message-----
From: Haslett, Andrew [mailto:andrew.haslett at ilc.gov.au]
Sent: Monday, December 01, 2003 6:01 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] OT - Getting started with Web development
I don't think that will work. IIS performs your authentication so won't
have the client details available.
You'll have to run a custom login form to get the user details or ask your
host to set up basic authentication (not overly secure).
If you're working in an intranet you can use integrated authentication.
(If you're using .Net you can use impersonation which is another step
further and allows you a little more control).
Cheers,
Andrew
-----Original Message-----
From: Jim DeMarco [mailto:Jdemarco at hshhp.org]
Sent: Tuesday, 2 December 2003 6:21 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] OT - Getting started with Web development
VB 5.0 will work as well I believe (I misstated VB 6.0 below). Just create
a class within the DLL with LoginName and Machine properties (returned from
your API calls).
Jim D.
-----Original Message-----
From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com]
Sent: Monday, December 01, 2003 2:28 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] OT - Getting started with Web development
Thank you Jim. I tried that, but unfortunately our IT people must have IIS
configured to accept anonymous access. The only ServerVariables that are
uniquely identifiable are REMOTE_ADDR and REMOTE_HOST. There is one machine
here loaded with VB 5.0 so I may be able to create that work-around you
suggested.
Mark
-----Original Message-----
From: Jim DeMarco [mailto:Jdemarco at hshhp.org]
Sent: Monday, December 01, 2003 1:19 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] OT - Getting started with Web development
Mark,
Here's code to get the logon name. I don't know about the machine name via
ASP but here's a URL that lists all the Request.ServerVariables you can use:
http://www.4guysfromrolla.com/webtech/092298-3.shtml
<%
'anonymous access must be disabled in IIS for this to work Response.Write
(Request.ServerVariables("LOGON_USER"))
%>
You do have the option however to use your existing VB/VBA code to grab user
name and machine. Just wrap it an ActiveX DLL and call that from your ASP
code (if you use VB 6.0 that is). (it's the option I'd take if there is no
server variable)
HTH,
Jim DeMarco
Director Product Development
Hudson Health Plan
-----Original Message-----
From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com]
Sent: Monday, December 01, 2003 12:02 PM
To: '[AccessD]'
Subject: RE: [AccessD] OT - Getting started with Web development
Drew,
I for one thank you for "Chapter 1". As for writing an article or a book, I
believe that you've already done most of the work. You have a searchable
archive of all of your posts for any given subject. I'd be willing to bet
you've already written it, you just need to gather it together.
I especially want to thank you for the "hit counter". It gave me a great
idea. I have been relying on the IT-provided WebTrends report for
statistics regarding the departmental website that I administer. But their
statistics are at the division level, not departmental.
One not-so-quick question regarding Access v. ASP... In a few of my Access
apps I utilize API calls to capture the login name and machine name of the
user. Is it possible to replicate that functionality using any combination
of ASP/HTML/VBScript? (I once had an UNIX instructor who's motto was "The
answer is always yes, the question is how.")
Thanks for any comments,
Mark
-----Original Message-----
From: Drew Wutka [mailto:DWUTKA at marlow.com]
Sent: Friday, November 28, 2003 7:07 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] OT - Getting started with Web development
I've thought about writing a long set of articles to put on my website, but
I always find something else comes up...know what I mean?
Drew
-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Wednesday, November 26, 2003 7:26 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] OT - Getting started with Web development
Hi Drew:
Have you ever thought about writing a book on the subject...You have
finished chapter one.
...I teasing... :-)
Very good introductory
Jim
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Drew Wutka
Sent: Wednesday, November 26, 2003 2:55 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] OT - Getting started with Web development
Paul, I have been developing ASP project for quite some time now. I think I
can narrow down what you REALLY need to know to get started.
First of all, before you dig into web development, you MUST understand how a
web server and web pages work. It is a whole different ball of wax compared
to an Access FE. With an Access FE, you create forms and reports, and each
user has a copy (or uses a shared FE) of the front end. This has several
drawbacks. First of all, if you have copies of the FE all over, you have to
create an update process to push out new changes. If you have a shared FE,
then you have to kick everyone out to update the process. On top of that, a
user can be anywhere, so there can always be issues of where things are
located. One user may have a share mapped to S, while another has it mapped
to T. UNC's can handle this, but then there is also the issue of whether
people are able to even get to the locations involved. On a web server, all
of these issues are moot.
The way a web server works, is the client opens their browser and requests a
web page. Let's say they go to http://MyWebsite.com. The browser does a
few things, one of which is it sends an http request to the server sitting
at whatever mywebsite.com resolves too. (http is Hyper Text Transfer
Protocol. HTML is Hyper Text Markup Language. So, HTTP is the protocol
uses to transport HTML.). The server at the other end gets an http request
for it's root directory. Notice the URL doesn't have a specific file (this
is a KEY point to remember). That is just fine and dandy, because a
webserver can be asked for a page by just the 'folder', since each folder
can have a default document setup. In most cases it is index.htm or
default.asp, but it can quite frankly be any document you want (or even a
list of documents). For our example, let's say it's default.asp. The web
server then reads the default.asp page and runs it through it's ISAPI
filters. These are filters that cause various things to be done to the HTML
that is going to be sent back. Two good examples of this are includes and
ASP itself. Includes are when you mark another file or files to be included
within the document. So, if you have a header that you want on every page,
instead of putting the HTML for that header on every page, you put the
header in it's own file, and just include it in all of your pages. The
include ISAPI filter then incorporates that HTML in the outgoing HTML. You
can also include .asp code, similar to putting code in a module, versus
behind every form/report. The ASP ISAPI filter is a little more complex.
Instead of just replacing text, it actually 'works' the ASP code on the
page.
This is the CORE of ASP. What the end user get's, is just the outgoing
HTML. They never get the ASP code itself. ASP can either be passive or
dynamic. My own terms for the two actions ASP can perform. Passive is when
the ASP does something that the users can't see. Dynamic is when ASP does
something that the users DO see. For example. If the default.asp page was
like this:
<%
dim cnn
dim rs
dim strSQL
set cnn=server.createobject("ADODB.Connection")
set rs=server.createobject("ADODB.Recordset")
cnn.Provider="Microsoft.Jet.OLEDB.4.0"
cnn.Open "E:\MyDB.mdb"
strSQL="SELECT Hit FROM tblHits;"
rs.Open strSQL,cnn,1,3
rs.AddNew
rs.Fields(0).value=1
rs.Update
rs.close
set rs=nothing
cnn.close
set cnn=nothing
%>
<HTML>
Hello
</HTML>
The end user will get a page that says hello, but internally, the ASP page
has added a record to a database, in this case, a simple hit counter. This
is passive, since the user will always get 'Hello', no matter what they do.
The ASP code is doing work, but it's something the end user doesn't see.
Dynamic ASP pages are where the output the user sees is directly affected by
the ASP code. To do this, you must either use the = symbol (which is a
shortcut to have the ASP send something out with the resulting HTML stream),
or the response.write procedure.
For example, let's have default.asp be this:
<%
dim strIP
strIP=request.ServerVariables("REMOTE_ADDR")
%>
<HTML>
Your IP Address is: <%=strIP%> <br>
<%
response.write "Have a nice day."
%>
</HTML>
What the user will see is a message that has their IP address, like this:
Your IP Address is: 65.65.125.209
Have a nice day.
We used the equal since to 'insert' something into the normal HTML with ASP,
and then we used response.write to directly output a string into the
outgoing HTML stream.
The last thing to remember when dealing with a web server is that the end
users are getting whatever the web server hands out, the moment they request
it. Once they get the resulting HTML stream, and their browser displays the
page, there is no longer a connection to the file they requested. That
means if you are constantly updating asp pages, the end users will just
simply get the 'current' results at the time of their request. No kicking
everyone out, etc. Pretty handy.
Three more items to cover. Above was the biggie. First of the three. HTML.
HTML is actually pretty simple. I personally used Front Page when I started
out, to let it do the HTML for me, then after a few months of going back and
forth, I just got the hang of it, and I rarely ever use FP for writing the
HTML anymore. The two key items to remember with HTML is that everything is
written with tags. Some tags are stand alone, such as <BR> (which is a line
break), and some tags must have a start and finish (<HTML> and </HTML>, or
an easier example <b> and </b> which is for bolding text). Tags also can
have properties. For example, an anchor tag (for hyperlinks) is a. <a
href="http://wolfwares.com">Click here to go to Wolfwares.com</a> <a starts
the tag, it has an href property, which is the URL of the site/file the
hyperlink points too, then the tag is closed with the >, and between the
start tag, and the closing tag </a>, there is text, which is what the user
will see as the text of the hyperlink. The second key item to remember with
HTML is that no matter what format you write the HTML in, what the user sees
in the browser is determine by the TAGS, not by the HTML code.
So if you write:
<HTML>
This is a
Test
</HTML>
The user sees:
This is a Test
If you write:
<HTML>This is a <br>Test</HTML>
The user sees:
This is a
Test
Second of the three is a BIG difference between Access and ASP. Access runs
it's code on the users processor. This is both good and bad. Bad, because
the end user must have Access (or a run-time installed). Also, bad because
users on slower machines are going to be delayed longer then users on fast
machines. Good, because as long as the end users have the correct
software/runtimes, your application should almost be gauranteed to work.
With ASP, if you write standard HTML, it doesn't matter what you have the
ASP code do. Your ASP code only has to run on the web server. Your clients
can be running Pentium 4's, with IE, or Mac's with Netscape, and everyone
sees the same results. A client running a 2.6 gigahertz on a 56k modem is
going to run your application at the same speed (well, pretty much the same
speed) as a client running a 486 66mhz with a 56k modem. In fact, if your
pages are light enough on the output (little to no graphics, just plain
HTML.....) there isn't going to be much of a difference between a modem user
or a broad band user. Text transfers pretty quickly....though you could have
slow downs if there is just a ton of text being sent (like combo boxes that
have thousands of items in their lists). The final issue with this part is
client side scripting. I personally stay away from it like the plague,
unless it's for in house projects where I know everyone is using IE. So try
to make your applications run strictly with ASP, unless absolutely
necessary.
Third of the three. The real nuts and bolts of ASP. ASP can be written in
JScript or VBScript. Quite frankly I have never bothered to use JScript,
since VBScript is practically second nature. When writting ASP, you enclose
the ASP code with <% and %> (start and end tags for ASP), and then write
away with VBScript. There are two things to remember/research. ASP is
VBScript with extra objects (Application,
ObjectContext,Request,ASPError,Response,Server,Session). The three you are
going to deal with the most are Request, Response and Server. Request gives
you access to what you have been 'sent' by the user. It can be used to read
cookies, server variables (which include Usernames, passwords,IP Addresses,
browser types, etc.), and form data. Response is what you use to send data
back to the user (response.write outputs to the HTML stream, redirect can
actually change the URL the end user is receiving, etc.). Server is the
webserver itself. The two main methods you will probably use are
MapPath(Which let's you map a virtual or actual path to a file) and
CreateObject. That CreateObject is the big catch with ASP and VBScript. In
normal VBScript you just call CreateObject. But with ASP, you must use the
Server Object's CreateObject method to create an object in VBScript.
(Because the object must be created by the webserver).
That's ASP in a nutshell. The first item I talked about is a little
difficult to figure out from the MSDN, the rest is in the MSDN, but can
still be a little difficult to figure out. The details on everything (HTML
tags, ASP objects, etc.) are pretty much well explained in the MSDN though.
The last thing you will need to know about ASP pages versus Access FE's is
how to get data FROM the user. (we already discussed sending it to them,
with the response.write method). I mentioned the request object. The two
methods of getting data from the user are through forms and querystrings. A
querystring is what follows a URL (after a ?). So, if you have a URL like
this: http://MyWebsite.com/default.asp?MyValue=10 , you can retrieve the
value of MyValue by using the request.QueryString method, like this:
<%
response.write request.QueryString("MyValue")
%>
If you have an HTML form, and you POST the data:
<HTML>
<BODY>
<Form Name="MyForm" Method=post action="results.asp">
<input type=text name="MyValue">
<input type=submit>
</form>
</body>
</HTML>
The resulting page will have a textbox, and a submit button. Pressing the
submit button will send the data within the MyValue textbox to results.asp.
So if results.asp was this:
<%
response.write request.form("MyValue")
%>
The results page will output whatever was in the textbox.
The key difference between a QueryString and a Form is that QueryStrings are
limited by the max length of a URL (which is, I think, 2048
characters...maybe 1024 characters, not sure). Where as a form is not
limited in the amount of data that can be submitted. You can also refer to
a request 'variable' by just the request object. request("MyValue") can be
a value in either a QueryString OR a Form.
Phew, what an email. This was fun to write though. Keep in mind that ASP
doesn't directly like DAO, so write your code using ADO. Feel free to
contact me offlist if you have specific questions. I may get hammered for
the length of this email, but I think it's pertinent to Access development
on the web!
Drew
-----Original Message-----
From: paul.hartland at fsmail.net [mailto:paul.hartland at fsmail.net]
Sent: Wednesday, November 26, 2003 9:55 AM
To: accessd
Subject: [AccessD] OT - Getting started with Web development
To all,
I'm looking to start writing web pages etc, secure logins, returning
resultsets in tables from Access & SQL Server etc. Anyone know any good
sites to get me started along with any book recommendations ? Thanks in
advance for all your help Paul Hartland
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
****************************************************************************
*******
"This electronic message is intended to be for the use only of the named
recipient, and may contain information from Hudson Health Plan (HHP) that is
confidential or privileged. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of the
contents of this message is strictly prohibited. If you have received this
message in error or are not the named recipient, please notify us
immediately, either by contacting the sender at the electronic mail address
noted above or calling HHP at (914) 631-1611. If you are not the intended
recipient, please do not forward this email to anyone, and delete and
destroy all copies of this message. Thank You".
****************************************************************************
*******
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
****************************************************************************
*******
"This electronic message is intended to be for the use only of the named
recipient, and may contain information from Hudson Health Plan (HHP) that is
confidential or privileged. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of the
contents of this message is strictly prohibited. If you have received this
message in error or are not the named recipient, please notify us
immediately, either by contacting the sender at the electronic mail address
noted above or calling HHP at (914) 631-1611. If you are not the intended
recipient, please do not forward this email to anyone, and delete and
destroy all copies of this message. Thank You".
****************************************************************************
*******
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
IMPORTANT - PLEASE READ ********************
This email and any files transmitted with it are confidential and may
contain information protected by law from disclosure.
If you have received this message in error, please notify the sender
immediately and delete this email from your system.
No warranty is given that this email or files, if attached to this
email, are free from computer viruses or other defects. They
are provided on the basis the user assumes all responsibility for
loss, damage or consequence resulting directly or indirectly from
their use, whether caused by the negligence of the sender or not.
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com