Comments
Sort by recent activity
Thanks for your post.
I've looked through our historic data here, and this error message has only cropped up once before. Unfortunately, the customer on that occasion never responded to our request for more detail so we never discovered it.
Thinking at the time was that is potentially a problem in the .net framework, but could you give a little more information:
- What exact version of SQL Data Compare are you using?
- Does this occur when working with two actual databases, or are you using script folders?
- Does the process succeed if you let SQL Data Compare perform the update (as opposed to generating a script)?
- Do your database(s) use any unusual collation?
- What do you have set in Tools > Application Options under the Synchronization Scripts Encoding option? Do any other options here work?
If you want to contact us directly to work through this, please mail us directly at support@red-gate.com, quoting F0045000 in the subject line. / comments
Thanks for your post.
I've looked through our historic data here, and this error message has only cropped up once before. Unfortunately, the customer on that occasion never responded to our request...
OK - it may also be worth turning up the logging to "verbose" to see if it gives anything more specific.
To do this, right-click the main SQL Data Compare window titlebar, and select Min Logging Level > Verbose.
Restart the app and generate your error, then check the log by right clicking once more on the titlebar and picking "Locate Log Files", then opening the most recent one. / comments
OK - it may also be worth turning up the logging to "verbose" to see if it gives anything more specific.
To do this, right-click the main SQL Data Compare window titlebar, and select Min Logging Le...
Also - are you mapping together any differing datatypes that may be incompatible? / comments
Also - are you mapping together any differing datatypes that may be incompatible?
Apologies for the delay in replying.
Well, as a general rule the process will take "as long as it takes".
You can speed it up by only including a subset of tables you're interested in (this will help the comparison phase) but for the actual sync it's basically executing an update/insert/delete script against the target server.
This is subject to what else the server is doing at the time, and other network traffic and so on.
I noticed you mentioned replication a lot in your messages. I'm not sure if this is exactly what you're using it for, but SQL Data Compare isn't really intended as a replacement for the full transactional replication offered within SQL Server itself. Whilst you can use it to move data from one db to another on a regular basis, it's only connecting to the server in the same way as any other client application and has to take its turn for resources like anything else. / comments
Apologies for the delay in replying.
Well, as a general rule the process will take "as long as it takes".
You can speed it up by only including a subset of tables you're interested in (this will he...
Sorry I didn't reply sooner to this.
Basically if the performance varies then there's unlikely to be much you can do to speed it up. If it had always been slow, then it could be worth looking in your code to see if improvements could be made (perhaps run our performance profiler against it) but if the only real variable is the time it happens to run at I don't think much can be done. Sorry. / comments
Sorry I didn't reply sooner to this.
Basically if the performance varies then there's unlikely to be much you can do to speed it up. If it had always been slow, then it could be worth looking in yo...
So restarting SQL helped? Seems odd, I wouldn't particularly expect that to affect it.
Is this a live production system? I can only think that varying loads on it are accounting for the differences. / comments
So restarting SQL helped? Seems odd, I wouldn't particularly expect that to affect it.
Is this a live production system? I can only think that varying loads on it are accounting for the differences.
Hi, Brian has already helped out in your other thread regarding this message.
I've just had a quick look in the code for the block executor and it looks like the commandtimeout is 6000 seconds, which would be 100 minutes? So I'm not sure that's entirely your problem.
Either way, it doesn't explain why it's now slower than it was. Did it change suddenly, or has it got slower over time?
Assuming nothing else has altered, has something happened to your network connection that's maybe slowing it down? Any other services added, or some other problem? / comments
Hi, Brian has already helped out in your other thread regarding this message.
I've just had a quick look in the code for the block executor and it looks like the commandtimeout is 6000 seconds, whi...
Indeed, it's a little odd. I'll keep an eye out for anyone else reporting the same and let the team know. / comments
Indeed, it's a little odd. I'll keep an eye out for anyone else reporting the same and let the team know.
Thanks for your post. I don't see this error being reported before, based on a quick search.
Could you maybe try the standalone installer for Prompt from here to see if it works? / comments
Thanks for your post. I don't see this error being reported before, based on a quick search.
Could you maybe try the standalone installer for Prompt from here to see if it works?
Thanks for your post. I'm not sure you'll easily be able to do what you want. It sounds like you're talking about merging data, and we have a document detailing "best practices" on this, here but it's quite geared towards designing things a certain way before you start using Compare- but see if it helps. / comments
Thanks for your post. I'm not sure you'll easily be able to do what you want. It sounds like you're talking about merging data, and we have a document detailing "best practices" on this, here but i...