August 21, 2002 at 12:22 pm
I am currently running SQL Server 2000 Standard. My database contains 6 million records. When I try to query this table I get ODBC timeout errors.
My question: What is the most amount of records that SQL standard can run with? Is there a way to get rid of the ODBC timeout errors? At what point (size) should I upgrade to SQL Enterprise.
Thanks
james
August 21, 2002 at 3:13 pm
I don't think there's a limit set in Standard. Performance is your limiting factor and likely the problem.
You can up the ODBC timeouts on the clients, but would need to apply some of the suggestions above to make it run faster.
Steve Jones
August 24, 2002 at 12:32 pm
I have broken down the table into 1.6 million records, but I am still getting the error. I changed the ODBC timeout from 0 to 600 and it didn't do anything for me. The other thing I tried was putting an index to index the download date field. I thought this would help considering each days download is about 175,000 records. Any other suggestions?
quote:
I don't think there's a limit set in Standard. Performance is your limiting factor and likely the problem.You can up the ODBC timeouts on the clients, but would need to apply some of the suggestions above to make it run faster.
Steve Jones
http://www.sqlservercentral.com/columnists/sjones
August 24, 2002 at 6:54 pm
1.6...or even 6 million rows isnt all that much. Definitely need to look at the query plan and hardware performance.
Andy
August 24, 2002 at 7:05 pm
If you can run this in QA
SET SHOWPLAN_TEXT ON
GO
YourQuery
GO
then post the output here and we can offer possible issue points.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
August 26, 2002 at 12:15 am
You do know you can't run a query from EM that takes longer than 30 secs yeah ?
So if you are using QA to do this you shouldn't strike timeout problems. Can you give us ODBC driver details etc ?
DB
The systems fine with no users loggged in. Can we keep it that way ?br>
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply