Comments
Sort by recent activity
Hi,
I'm pretty sure you've hit a known bug in SQL Data Compare 6.0 - the selections you make in the GUI aren't used by the command line; instead, the command line takes the list of objects to include and exclude from any /include and /exclude switches you may pass it.
We've fixed this in version 6.1, which is due to be released in the next few days, whereby any tables you exclude in the GUI will also be excluded when you run the command line version. This will work in addition to any /include and /exclude switches you may use.
Version 6.1 will be a free upgrade if you've got 6.0.
Hope that helps,
Robert / comments
Hi,
I'm pretty sure you've hit a known bug in SQL Data Compare 6.0 - the selections you make in the GUI aren't used by the command line; instead, the command line takes the list of objects to inclu...
Hi,
Just to let you know, 6.1 is now out. You can get this by going to Check for Updates on the Help menu.
Robert / comments
Hi,
Just to let you know, 6.1 is now out. You can get this by going to Check for Updates on the Help menu.
Robert
Hi,
When comparing backups, yes, you need to have some kind of index on the tables in order to compare them. This can be clustered or non-clustered, with clustered indexes generally giving superior performance (as you'd expect in SQL Server itself).
Hope that helps,
Robert / comments
Hi,
When comparing backups, yes, you need to have some kind of index on the tables in order to compare them. This can be clustered or non-clustered, with clustered indexes generally giving superior...
Hi,
We've just released Data Compare 6.1, which fixes a number of bugs. This is a free upgrade if you're currently a Data Compare 6.0 user, so it might be worth a try if you're still having problems. You can download the latest version by going to Check for Updates on the Help menu.
Robert / comments
Hi,
We've just released Data Compare 6.1, which fixes a number of bugs. This is a free upgrade if you're currently a Data Compare 6.0 user, so it might be worth a try if you're still having problem...
Hi,
Thanks for the reply. I suspect it's the initial parsing of the backup that's taking the majority of the time. I've just given it a quick test with a 3GB SQL Backup File (native backup would be about 10GB, original database about 30GB), and it took about five minutes to register and retrieve the schema.
I'm afraid it does take a while on larger backups - unfortunately the layout of the backup file isn't deterministic, so we have to do an initial scan of the whole file before we can get any information out.
Depending on the relative speed of your processor and disk, you might find some compression levels are better than others - on a fast CPU, higher compression will be quicker since there will be less disk access, but on a slower CPU, the disk won't be the critical factor but the CPU will.
Another thing you might want to try is using multiple threads in your backups - especially if your machine is dual-processor/core/hyperthreaded. The effect isn't particularly huge on the main comparison process, but more threads could speed up the initial registration. Again, it depends on how saturated your CPU is.
Hope that helps,
Robert / comments
Hi,
Thanks for the reply. I suspect it's the initial parsing of the backup that's taking the majority of the time. I've just given it a quick test with a 3GB SQL Backup File (native backup would be...
Hi,
Hmm... that's obviously not meant to happen! Are you able to compare the live database to itself? That should hopefully establish whether it's the backup half of things that's causing the problem.
Assuming the compare of live to live works OK, I wonder if you could create a folder named "logs" within your SQL Data Compare installation directory, ensuring that your user has permissions to write to it. Restart Data Compare, and try running the comparison from the backup again (if you save the project, you won't have to wait for it to retrieve the schema every time to let you select only the one table).
This should result in some files being left in the logs directory. If you could email these to me (robert dot chipperfield@red-gate.com), that'd be really useful, and I can try and track down what's going on.
Sorry this hasn't worked for you straight out of the box...
Robert / comments
Hi,
Hmm... that's obviously not meant to happen! Are you able to compare the live database to itself? That should hopefully establish whether it's the backup half of things that's causing the probl...
Hi,
I wonder if you could let me know some more details about the databases you're working with (rough numbers only, of course)
- How big is the backup?
- Are there a very large number (thousands, tens of thousands, that sort of number) of tables or views?
- Is the backup a "native" SQL Server backup, or a Red Gate SQL Backup backup?
Also, when you're waiting for it to retrieve the schema, what sort of CPU and hard disk activity are you seeing? Chances are one of those is the limiting factor, but it could be either.
Thanks,
Robert / comments
Hi,
I wonder if you could let me know some more details about the databases you're working with (rough numbers only, of course)
- How big is the backup?
- Are there a very large number (thousands, ...
Hi anshulabhat,
If you're referring to SQL Compare, I'll leave someone else to come back to you on your other post - this thread was originally related to SQL Data Compare, which is currently at version 6.1.1.
With regards to SQL Data Compare, I'm afraid in v6.1.1 we don't apply selections made in the UI projects when run via the command line. Instead, you can use the /include and /exclude switches on the command line to specify the objects you wish to compare and synchronise.
Hopefully the next release of Data Compare will address this issue, and mean that selections made in UI projects are used in the command line as well.
Many thanks,
Robert / comments
Hi anshulabhat,
If you're referring to SQL Compare, I'll leave someone else to come back to you on your other post - this thread was originally related to SQL Data Compare, which is currently at ve...
Hi,
When you run the project in the GUI, had you unselected some tables? If so, in version 6.0, the command line ignored these selections when running a GUI project file.
This was fixed in version 6.1, released this morning. If you run Check for Updates (on the Help menu), you should be able to download 6.1.
If you're still having problems under 6.1, then we'll have another think!
Thanks,
Robert / comments
Hi,
When you run the project in the GUI, had you unselected some tables? If so, in version 6.0, the command line ignored these selections when running a GUI project file.
This was fixed in version ...
Hi,
Thanks for the reply... bother, I thought that would work! Could you confirm the type of exception and stack trace you're getting with 6.1? I'm pretty sure it won't still be the SqlNullValueException you saw in 6.0, but it's worth checking...
Thanks,
Robert / comments
Hi,
Thanks for the reply... bother, I thought that would work! Could you confirm the type of exception and stack trace you're getting with 6.1? I'm pretty sure it won't still be the SqlNullValueExc...