Very well put. "Colorful" style and all, that man has saved countless people from themselves and hopefully when he weighs in with a decidedly negative opinion, people at least take notice and do some DD to try to prove (to themselves at least) that he's wrong.
Never wrong, though? Nah, he's made his share of mistakes. Didn't he get Kremed a while back?
All, I'm rebooting both machines as soon as I send this, since I'm hearing of timeout and access problems. The log files will be started from scratch, too.
If it all possible, try to give Matt the exact time you got an error message, how long the system seemed to "hang" before an error message popped up, and the exact text of the error.
The error that Matt reported to me is a bit of a toughie. The SQL box hasn't broke a sweat since I quite logging web-access data to it. Hasn't ever gotten past 67% utilization in the past couple of days.
The line that's bombing out (at least, the error Matt shows me) is an UPDATE query. Those *can* be real expensive in large tables, but this one doesn't look like it should be too bad. For the geeks out there, it's updating one field and using a WHERE clause that just happens to be the primary key. Shouldn't be too bad.
One of the projects after my current one is to go through all of the site's code, one ASP at a time and both convert them to CSS, and convert all ad-hoc queries to stored procedures. I'm already doing this with any ASP's I'm going through extensively right now on my current project.
This one's a bit of a head-scratcher since I don't see why the query should take so long, as all it's doing is marking a message "Read" when the recipient has read it. It could be that that table has so many indexes, which does tend to slow down UPDATEs, although I would think that's true only if an indexed field is being UPDATEd. Dunno.
In any event, so I can get back to what I was doing, I'm gonna cop out and just reboot both boxes. They'll be back in a minute or less.
Bob
News 
Market Data 
Discover 
AI
