Open nhgrif opened 10 years ago
Again, this is happening on SQL Server 2008 R2 and SQL Sever 2005
In SQLClient.m, dbsetlogintime(self.timeout); is called. However, this seems to only apply to login times (I've not been able to successfully test whether or not this one is actually working or not). However, FreeTDS also has a function called dbsettime() which is supposed to set timeouts for queries. I'm trying to get this to work, but no luck so far.
Yes, I can't get dbsettime() to work either. Going to have to do a workaround.
Martin, I suspected that the reason the query wasn't timing out with the above example was because the dbsettime() only cares about the time between beginning the query and getting the first response. It seems my suspicion was accurate. When I lock up a table using BEGIN TRANSACTION, then through your SQLClient, try to execute a query on the locked table, I am able to get error # 20003, Adaptive Server connection timed out with severity 6. This is only after adding a called to dbsettime() though (I was using 1 second for testing purposes).
It might be nice to have a workaround for timing out query after the initial response, but for now at least, dbsettime() should be included.
I've created pull requests. You may see a better way to implement this. I'll close this issue when everything is updated. Renaming the "timeout" property to "loginTimeout" might be something to consider as well.
Thanks so much for your help! I appreciate it.
I've set a timeout value of 3 (this is 3 seconds, right?).
I've executed a query to select 30,000 rows from a table with several columns (in practice, I don't need a result this big, but I'm forcing the issue here). Timing the query results in a time of over 4 seconds. This doesn't count the time to display or do anything with the date. The first time is marked just before execute is called and the second time is marked as the first line in the completion block of the execute method. The query should have timed out before this.