Andy Lacey
andy at minstersystems.co.uk
Thu Nov 27 05:12:25 CST 2003
No Way you're going to "get hammered". The mods may take a (friendly) stick
to you sometimes when you go off on one about beer, traffic or whatever but
rest assured we hugely appreciate the efforts you make to help people on
this list. And I second Jim's call - Write a book, or at least a series of
aticles for Many-To-Many. Susan's tking of another issue soon so this would
be a terrific subject.
Andy Lacey
http://www.minstersystems.co.uk
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
> Sent: 26 November 2003 22:55
> 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/a> ccessd
> Website:
> http://www.databaseadvisors.com
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/a> ccessd
> Website:
> http://www.databaseadvisors.com
>
>