good vb habits in ASP w/ recordsets 3

[imarosel]

Hello,

I have some experience in vb with access, and am currently cutting my teeth with vbscript on an asp website. I have noticed that the code I inherited does not "close" recordsets at the end of functions etc. like I was taught to do with vb in access. i.e. recordset.close, set recordset=nothing etc. Is this normally done in vbscript?

 

[Sheco]

Yes, close recordsets and set them to nothing as soon as you don't need them.... same for connections.

If you need the recordset for a while longer, but you won't be performing anymore operations besides MoveNext, you could set the ActiveConnection property of the recordset to Nothing and then get rid of the Connection object... leaving you with a disconnected recordset that is still useful.

 

[imarosel]

Now i've got a lot of work to do, thanks.

 

[Sheco]

OK but it is just good practice, not a requirement.

But if you just inherited an ASP application and are sort learning while familiarizing yourself with the existing code then this would be a nice project to accomplish multiple tasks at once... in a meaningful way that is perhaps more mentally engaging that just plain studying the existing code.

 

[imarosel]

True that, I don't mind updating it all. I like to develop good habits from the start. How about declaring variables? Seems to me that is not required in ASP either.

 

[tsdragon]

Not only is it not required, but sometimes to me seems a total waste of time, since you can't declare a type with them.

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Tarwn]

If you put an Option explicit at the head of your script file, vriable declaration will be required. I disagree with the previous poster on this being a total waste of time and in fact I believe that not using Option Explicit and declaring all of your variables is a greater waste of time.
Telling the script engine (via Option Explicit) to enforce variable declaration gets you two advantages over not doing it. The first advantage to this method is in the debugging stage. When your debugging the interpretr will spit out errors when it runs into an undeclared variable. This can save you hours of scouring through code when you acidentally mispell a couple variables because the interpreter kindly points out where the variable is, giving you a solution time of a few minutes.
The second advantage to forced declaration is a runtime advantage. When you Dim a variable it is assigned an ordinal that will be used bythe interpreter to reference it. Un-dimmed variables instead must be text-matched against each existing variable (then created if a match isn't found). So basically you have direct access vs a full scale text search against the other variables, posibly followed by the creation process. I have seen numbers reporting a 10% performance increase in using Option Explicit and Dimming every variable.

The last argument I have for declaring all of your variables is towards Good Practice. By declaring your variables ahead of time, you can comment individual variables, determine if they need initial values, etc before you actual use them. When someone goes back through to read your code they see these declarations (and possibly comments) and already have some expectations as to what they are goingto see or be used for, whereas just creating variables on the fly can often confuse the reader. Additionally, by declaring variables ahead of time you are generally forced to think of better names for them, even if it is so you have an easier time remembering what they are for 30 lines later.

All in all, my advice is to use Option Explicit religously. There is no reason to not use it, short of laziness, and it's advantages are extremely useful.

 

[tsdragon]

Thanks for calling me lazy. In my regular VB programs I ALWAYS use option explicit. I like the fact that it requires variable declaration. In my VBScript programs I don't generally use it, but I DO still usually dim my variables first. It just seems stupid to have to do so when you can't declare a type for them as well.

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Tarwn]

Tracy: I apologize if it sounded like I was calling you lazy, I hadn't intended that at all. I was merely trying to make the point that if a programmer knew the advantages of declaration and Option Explicit and then decided not to utilize it, that they were being lazy. By your earlier post I assume you didn't know of the advantages, and thus don't fall into that category.

-T

 

[DotNetGnat]

Tarwn,

Nice post about the advantages of using Option Explicit.

Thanks

-DNG

 

[imarosel]

definitely a nice post, thanks.

 

[theniteowl]

imarosel,
Another practice I have found very useful is to put your connect string into a separate file and include that file on any page you need to make a connection from.
This way if you have to make an update to the connection string you can do it in a single place instead of having to search through many files to get at all instances of it.

For instance, if your server name changed or the DB was moved to a new server, only a single change in the code would be necessary to accomodate the move.


Paranoid? ME?? WHO WANTS TO KNOW????

 

[Sheco]

I like to set an Application variable for the ADO connection strings. I set it in the global.asa file inside the Application_onStart event handler function.

 

[theniteowl]

I guess that would work too.
I have no experience with the global.asa file, time to learn but others things keeping pressing down on me.

We have one application where all the connection and query strings were compiled into a DLL as a method of security for the application. Makes it much more difficult to determine the id/password to get into the database and somewhat more difficult to tell how the application operates. You can see what values are passed in but not the query string they are used in.

Any opinions on this method? Is there a better way?
Apart from stored procedures anyway.


Paranoid? ME?? WHO WANTS TO KNOW????

 

[Sheco]

Compiled code is certainly more secure from the casual browser but on the other hand it is more difficult to deal with when the connection string changes.

If you really want to hide your code then you can actually make a DLL to run inside MTS/COM+... you could have your entire site made of one tiny ASP like this:
<%
ob = Server.CreateObject("MySite.Haha")
ob.ShowPage
Set ob = Nothing
%>

Of course the inside of the DLL would be nasty... inside the ShowPage method you'd call GetObjectContext to get a reference to the ASP that called your DLL... then you'd use that context to read the Request, Session, and Application objects and write to the Response object.

This is an extreme example of hiding your code and it is also an extreme pain in the butt to modify it.

 

[tsdragon]

Tarwn: Sorry, I was being overly touchy. I know you didn't mean anything. You're right, I didn't realize the advantages of using option explicit in vbscript, but could see the obvious advantages of using it in regular VB. Thanks for the explantation. I gave you a star for educating me.

theniteowl: We do the same thing where I work. Not only does it make it easy to change, but it prevents typograpical errors as well. If you're accessing multiple databases, or especially multiple servers, it becomes even more useful.

Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[Tarwn]

I'm not crazy about creating a DLL strictly to hold onto a connection string. I could understand encapsulating all the database connecitons and such into an object, but even then I think I would want to keep the connection string seperate.
Warning, this is entirely my opinion, so don't take it as a rule or anything like that
Personally I prefer to have one central include file where the database conneciton strings are defined. I am not concerned about security because:
1) Obscurity - someone has to know what the filename/folder is in order to get to the file
2) Extension - I give it an .asp extension so that even if they know the filename, they don't get anything useful - plus you can add a short script to the top of the include file to make it look non-existant
3) If they have ftp access or something to see the contents of the file, I have much bigger problems

The advantages, OTOH, are:
1) Centralized connection string (same advtange with a DLL)
2) Easy to edit - if I have to move the site I just change the file, no recompiles or anything
3) Hooking to a test db is much easier, again I don't have to recompile to move to a test DB then again to move back
4) Maintainability - lose the source to the DLL and you will probably have to rewrite it from scratch eventually, even though the site has been working without it for years - lose the source for the ASP include file and you will have to rebuild it immediately

Plus I don't see a lot of efficiency gains if all your doing is encapsulating a connection string in the DLL.

At the same time, I am not a huge fan of encapsulating ASP pages in DLL's at all. Granted you get a performance gain, but if performance is that largea requirement to you, ASP.Net may be a better choice now. I have had to rebuild to many websites that were entirely encapsulated in DLL's. On top of that, many of the sites I have rebuilt have actually been faster in ASP. I think encapsulating a site into a DLL should be the absolute last resort, after you have learned as much as posible about optimizing your VBScript. Some of the concepts of optimization can be re-used as you write a DLL and some of the early concepts (like only querying for the data you absolutely need, etc) are re-useable as concepts in any language.

---
Back to the include script for a moment:
If you are concerned about someone somehow loading your include page, you can add a simple piece of code that will prevent them from realizing your file even exists. Basically all you need to do at the top of the page is check what URL is being requested (from Request.ServerVariables) against the name of the include file. If they match then the user is requesting the pagedirectly, so simply use Response.Status to give them a 404 and Response.End it. All done

-T