Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 Timeout Expired when updating a large recordset

Author  Topic 

AskSQLTeam
Ask SQLTeam Question

0 Posts

Posted - 2002-12-26 : 10:39:42
drman writes "I am updating about 40,000 records (one field in the table) using a stored procedure. There is always the chance that the update could be much larger than 40,000 records. I receive an error message as follows:

[Microsoft][ODBC SQL Server Driver] Timeout expired.

I do not always get this message, which further concerns me. Is this a problem with my code or the server?

Please give me some direction. The problem did not exist when updating small amouts of data.

Thanks

drman"

mfemenel
Professor Frink

1421 Posts

Posted - 2002-12-26 : 11:06:42
Well, there's not going to be a quick and easy answer for you on this one. There's 2 things that come to mind right away that might cost you some update time. First is indexing. Do you know what % full your indexes are? A table that gets a lot of updates like that probably shouldn't be indexed to 100% full. It might be reasonable if you're updating a table that large to drop the indexes, update, then rebuild the indexes. 40K rows doesn't lead me to believe you're using a where clause, so this might be a good idea. Second, and it's rare that I've seen this set, is to check the settings on the database. Occasionally well meaning DBA's set up a query governor to make your life hell. From Enterprise manager, right click on the database and choose properties, go to the server settings tab and see what is set for the option "Use query governor to...." If that is set, talk to your DBA and see why that's set and if it's ok to adjust that when you do an update if you set it back. Those are a few good places to start. If none of these things work or makes sense to you, let us know what indexes you have on your table, what fields you're updating and how that update statement is written, also how many records are in the table. This might give us a better idea as well. Good luck!

Mike
"oh, that monkey is going to pay"
Go to Top of Page
   

- Advertisement -