MartyConnelly
martyconnelly at shaw.ca
Tue Dec 2 13:54:33 CST 2003
One of the interesting things you can do with .Net deployment, is to use
the Updater Application Block.
http://builder.com.com/5100-6389-5077516.html?tag=e606
Drew Wutka wrote:
>You can get the IP address of the client though. If you aren't getting
>clients that are behind a proxy, then you just have to reverse DNS to get
>their machine name.
>
>Drew
>
>-----Original Message-----
>From: Jim DeMarco [mailto:Jdemarco at hshhp.org]
>Sent: Tuesday, December 02, 2003 8:15 AM
>To: Access Developers discussion and problem solving
>Subject: RE: [AccessD] OT - Getting started with Web development
>
>
>Each folder does have its own authentication settings but it still won't
>give access to the machine name. If the DLL is used it may need to be
>installed on user's PC's and accessed via client side scripting. Unless
>scripting alone can access the API's then it's not even necessary.
>
>Jim DeMarco
>
>-----Original Message-----
>From: Haslett, Andrew [mailto:andrew.haslett at ilc.gov.au]
>Sent: Monday, December 01, 2003 9:09 PM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] OT - Getting started with Web development
>
>
>If you host your app in a virtual directory, then any changes you make will
>only affect your web application. They don't need to change any 'global
>iis' settings, so that should keep your network admins happy.
>
>I really think it's the easiest way to go rather than using dll's or client
>side script. All you have to do is check one box and you're laughing!
>
>Another point to remember: The IE6 option, under advanced->tools, called
>"Enable Windows Integrated Authentication" can affect whether the server
>variables (LOGON_USER) returns anything. Might pay to change that and see
>if it fixes your initial problem.
>
>Cheers,
>Andrew
>
>-----Original Message-----
>From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com]
>Sent: Tuesday, 2 December 2003 9:46 AM
>To: 'Access Developers discussion and problem solving'
>Subject: RE: [AccessD] OT - Getting started with Web development
>
>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
>_______________________________________________
>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
>
>
>****************************************************************************
>*******
>"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
>
>
>
--
Marty Connelly
Victoria, B.C.
Canada