How can we help you today? How can we help you today?

SQL Data Compare 7.1 checksum timeout from job

I have something strange..

I have a job (run from a batch file) that compares 2 local SQL databases on a SQL2005 box, and and synchronizes the changes. A SQL job calls a batch file. The batch file calls SQLDataCompare.exe, and gets the settings from a .sdc project file. This all works like a charm, and has been working for over a year, although a bit slow (12M large records). I don't use checksum comparison yet, but I want to.

When I enable checksum comparison in the project file, and I run the batch file, it works like a charm. Takes about 15 minutes.

However, when I now call the batch file from my sql job, it times out in around 60 seconds, and puts the following in my log:
Red Gate SQL Data Compare Command Line Utility V7.1.0.245
==============================================================================
Copyright c Red Gate Software Ltd 1999-2008
Serial Number:************
Loading synchronization parameters from project file: d:\scripts\syncXXXMasterToINFX.sdc
OK
Comparing database (local).XXXMaster with database (local).XXXINFX...
Registering databases
Mapping
Comparing databases
Error: Comparison of '(local).XXXMaster' and
'(local).XXXINFX' failed: Timeout expired. The timeout period
elapsed prior to completion of the operation or the server is not responding.
Conditional Fast Rowcount method requested without specifying an expected count.Fast method will be used.

I can run it manually fine. If I remove the checksum option, it runs fine from the job again.

Any ideas anyone!?
ahongens
0

Comments

1 comment

Sort by
  • James B
    Thanks for your post. I've found a couple of instances of similar messages from other posts and supportcalls. There is a post here: http://www.red-gate.com/messageboard/vi ... php?t=5803 which details a registry key you can put in to increase the timeout on the checksum query (from what I gather, it still needs to go under the Compare 5 section) which may help.

    I'm not sure why it would run ok from the commandline directly as opposed to a SQL Job, unless SQL Server somehow treats processes started as a SQL Job differently.

    If the registry key doesn't help, perhaps try downloading a trial of version 8 to see if the problem persists, as I don't see any recent reports of this particular message.
    James B
    0

Add comment

Please sign in to leave a comment.