OK, I fixed it
By Richard Rost
10 years ago
I was finally able to recreate the problem that has been plaguing a few users for a while now. When you sign up for emails to tell you that the Forums or News Feed (what you're reading now) have been updated, you get a link to click on to come directly here (or to the Forum in question). That link could sometimes freeze and take MINUTES to load, and even then display gibberish.
Well, I finally figured out what the problem is. It was a programming conflict caused by yours truly which involves laziness, shortcuts, and having web site code that's been copied, pasted, and crossed like lights on a Christmas tree.
For those of you who don't care about programming, rest assured the problem has been fixed.
For the rest of you, here's a teaching moment...
I have a global function called MakeLogEntry() which is #included in the ASP of just about every page on my site. It allows me to create my own database log files. The IIS text logs are inadequate so I made my own. In any case, this function works great 99.999% of the time.
However... since I've recently been moving things around, changing code on the fly, yadda yadda yadda... a problem came up where I ended up accidentally having multiple conflicting recordsets loading on the same page. This would ONLY happen if the new user logon code tried to pull up your user record AT THE SAME TIME as trying to save your automatic login attempt to the log file.
Oops. This caused an endless loop and a gibberish recordset to try and display garbage until the script timed out... at about 2 minutes.
Once I discovered the problem it was an easy fix. HOWEVER, this problem wouldn't happened in the first place if I had just not been lazy and properly DIMmed my variables in my functions. See the function looks kind like this:
set conn = ... database connection
set rs = ... recordset
record the data
set rs = nothing
set conn = nothing
OK, that's all fine and dandy, but if you don't DIM your variables INSIDE the function, ASP/VB assumes that if the variable already exists on the page that you want to use THAT variable. So when my function code is #included inside another page, if there's already a CONN or RS variable (which there was in this case) it uses those... then destroys those (=Nothing) and that caused the problem.
All I had to do was add one line of code to fix the problem:
Dim Conn, rs
And now those are LOCAL variables inside the function. The other recordsets on the page don't have a cow, and all is well with the world. See... being a lazy programmer WILL come back to bite you in the ass.
Thanks to Chris, Willem, Phillip, Alex, and everyone else who helped me to nail down this problem! You guys are the best.
Comments for OK, I fixed it