Comments
Sort by recent activity
I upgraded to the latest version. So far (knock on wood) I haven't experienced any timeout issue. However, doing a data compare on 30 tables used to take about 10 minutes on the average...with these new libraries it takes close to 20 minutes on the average. This happened immediately after I switched to the new libraries. Hopefully, the extra time makes it more reliable...but at double the time I'm not sure how feasible it is to use. Is there a reason that it takes twice as long between v6 and v9? Is there any way I can speed it up using a redgate library function? / comments
I upgraded to the latest version. So far (knock on wood) I haven't experienced any timeout issue. However, doing a data compare on 30 tables used to take about 10 minutes on the average...with th...
Okay, so we've established that it's a connection issue since the exception is always thrown in the RegisterForDataCompare function, correct? Yes, I can connect fine in SSMS when this problem happens. Perhaps the redgate connections are NOT being freed up (do I need to call a redgate function to do this) and no more can be established until I restart SQL server? / comments
Okay, so we've established that it's a connection issue since the exception is always thrown in the RegisterForDataCompare function, correct? Yes, I can connect fine in SSMS when this problem happ...
My version is 6.2.2.14 from April 2010. Was there a bug in this version? / comments
My version is 6.2.2.14 from April 2010. Was there a bug in this version?
Which redgate connection is timing out in this case (I gave you the stack trace). Also, what is the Redgate RegisterForDataCompare function supposed to be doing? That is where the timeout is occurring. I can't troubleshoot this function since there's no source for it. I really need your help to figure out why the exception is getting thrown in this function. I'm guessing the connection timeout is set to 100 minutes since no command is running...but I really need to verify. Please help me verify this. Thank you. / comments
Which redgate connection is timing out in this case (I gave you the stack trace). Also, what is the Redgate RegisterForDataCompare function supposed to be doing? That is where the timeout is occu...
I'm confused now. First, it was a connectivity issue where the connection was timing out (as shown in the stack trace). Now it's a command timeout? Wouldn't the exception get thown on a SQLcommand instead of a SQLconnection if this was the case?
Yes, I have used the sp_who2 and no sysprocesses are getting blocked when this is happening. However, there is no redgate SYSPROCESS to BLOCK anyway (unusual since there is always one running when everything is working correctly) during the period before the timeout eventually occurs. Again there is no select command that can get timed out since there is no redgate sysprocess running...so what does this exception mean anyway?
Anyway, it sounds like changing the connection timeout to 20 minutes will have no effect since the timeout occurs after 100 minutes. Correct? / comments
I'm confused now. First, it was a connectivity issue where the connection was timing out (as shown in the stack trace). Now it's a command timeout? Wouldn't the exception get thown on a SQLcomma...
Thanks, but it's timing out after 100 minutes (6002-6003 seconds) just for one table so will changing the timeout to 20 minutes help? Since we're currently not setting timeout for connection or command, what are the default values that redgate is using? / comments
Thanks, but it's timing out after 100 minutes (6002-6003 seconds) just for one table so will changing the timeout to 20 minutes help? Since we're currently not setting timeout for connection or co...
It's just one table. It is usually around 20,000 rows (it gets cleared out every hour after the data is moved to the destination server). The destination server isn't rebooted...SQL server is just stopped and restarted.
What connectivity problem are you referring to? / comments
It's just one table. It is usually around 20,000 rows (it gets cleared out every hour after the data is moved to the destination server). The destination server isn't rebooted...SQL server is jus...
Sorry about the "replication" terminology. Basically, we're only updating changed table rows using a lastUpdate field. I'm just trying to find out why the excute time is slowing down so much now. It's not consistent but when it's slow, it's sloooooooow. It sounds like there is just too much of a load on SQL server and there's nothing I can do with the redgate libraries to speed this up, would you agree? / comments
Sorry about the "replication" terminology. Basically, we're only updating changed table rows using a lastUpdate field. I'm just trying to find out why the excute time is slowing down so much now....
Restarting SQL was the only way I was able to stop getting the 2 hour timeouts trying to replicate the tables.
Yes, this is a live production system. Today, we had a record breaking 35 minutes to replicate 21 tables. Something is definately wrong. [image] / comments
Restarting SQL was the only way I was able to stop getting the 2 hour timeouts trying to replicate the tables.
Yes, this is a live production system. Today, we had a record breaking 35 minutes to ...