That reminds me of the three commandments of ASP Programming
(can't remember where I read them but it's true)
1.
Always Use "Option Explicit"
2.
Never Place an objects in a session variables or application variables
3.
Always use a OLEDB connection instead of ODBC
I found it after searching
<quote>
If you have stored an ADO connection object in an application level variable, you know that the variable is maintained till the Web server is shut down (the application ends). However, did you know that the variable is maintained on a specific thread? This is referred to as thread affinity. Any script that tries to access the variable has to either be on the same thread to make the call or must translate the call to the specific thread (a process called marshalling), which is a very expensive call to make. This results in lower performance.
If more than one ASP page is trying to make a call to a specific thread, they are placed in a row, one after the other to wait their turn before they can make the call. They are forced to run in a sequence. This is called serialization. Again, this results in performance degradation as your site serves more and more requests.
IIS is built to operate on multiple threads—a multi-threaded application. By placing objects in application level variables and forcing the Web application to wait for a specific thread to become active and run within it, you are forcing IIS to behave like a single threaded, inefficient application—effectively crippling its power.
</quote>
_________________________________________________________
for the best results to your questions: FAQ333-2924
01001111 01101110 01110000 01101110 01110100
[/sub]