Comments
Sort by recent activity
We've now fixed this in SQL Compare 7. There should be a new version of Packager in the next few months with SQL Server 2008 support which will have this fix in. / comments
We've now fixed this in SQL Compare 7. There should be a new version of Packager in the next few months with SQL Server 2008 support which will have this fix in.
I'm afraid you've come across a bug in our dependancy handling, and there isn't an obvious workaround other than taking the functions out of the check constraints before synchronizing, or manually synchronizing the assemblies.
I've forwarded this issue to the relevant developer, but we've just frozen development on 6.1 so I can't give you a timescale for when a fix will be available. (Hopefully we'll be able to get it into the next point release, which is mostly dealing with source control issues, but dependancy issues concerning CLR objects are quite tricky, so it depends how much development time we have available.) / comments
I'm afraid you've come across a bug in our dependancy handling, and there isn't an obvious workaround other than taking the functions out of the check constraints before synchronizing, or manually ...
Hi Bill,
I had a look through our bug database and I couldn't find any examples for this problem. If you could send me your examples (michelle.taylor@red-gate.com) then I'll take a look at the issue.
(I tried a simple case - adding a nullable column in the middle of a table and reordering the columns to force a rebuild - but that just inserted the old values into the old columns and left the new column alone for SQL Server to automatically fill with NULLs. Just adding a nullable column didn't force a rebuild in my simple example.)
Thanks for your report,
Michelle Taylor / comments
Hi Bill,
I had a look through our bug database and I couldn't find any examples for this problem. If you could send me your examples (michelle.taylor@red-gate.com) then I'll take a look at the issu...
Comparing triggers as seperate objects from their tables is another item on the list of things we are planning for SQL Compare, but again it's a major feature that will take some time to see the light of day. / comments
Comparing triggers as seperate objects from their tables is another item on the list of things we are planning for SQL Compare, but again it's a major feature that will take some time to see the li...
SQL Compare shouldn't be comparing the order of trigger application when it decides whether to flag an object as 'Identical' or 'Different' in the main grid. However, if you look at the SQL Difference pane, you may see triggers looking 'different' on account of being in a different order. This is because the SQL Difference pane just takes the SQL creation script that SQL Server has for the object and does a textual comparison, not the more sophisticated comparison that SQL Compare does internally - this is for performance reasons.
If the object is flagged as 'different' in the main 'grid', then there is almost certainly some other difference in the object than just the order of application of triggers. (If there is no other difference, we'd like to know about it, because that would be a bug!)
As for the server error message, that's the generic error message that SQL Compare gives for 'I can't find the server', no matter what the server's version is. The mention of 2005 is just a troubleshooting tip that might apply if you're connecting to a 2005 server - back when 2005 was new, we had a lot of support calls which were resolved by enabling remote connections on 2005 servers.
Can you connect to the server with Query Analyzer or Management Studio from the same computer and using the same login method as you are trying to use for Compare? (The normal cause of that error message is either mistyping the server name or some kind of networking problem - SQL Compare just can't even find the server to talk to it.) / comments
SQL Compare shouldn't be comparing the order of trigger application when it decides whether to flag an object as 'Identical' or 'Different' in the main grid. However, if you look at the SQL Differe...
Does SQL Compare show the *table* as different (in the main section of the screen), with no other differences present in the table? If the table is shown as identical, then SQL Compare is functioning correctly and won't try to synchronize the 'differences' you're seeing.
The triggers show up as different in the SQL Differences pane at the bottom because SQL Compare is just comparing the text of the entire 'Triggers' section of the creation script, which is different because the triggers are in a different order.
'Make the SQL Differences pane comparison more sophisticated' is on our list of things to do, but it will be an enormous undertaking, so I'm afraid you probably won't see it for a while. / comments
Does SQL Compare show the *table* as different (in the main section of the screen), with no other differences present in the table? If the table is shown as identical, then SQL Compare is functioni...
The problem isn't that the database is on a remote server, but that the new target server is a 2005 server. Whilst we can get around the encryption on 2000 servers and retrieve details about the objects, we can't do that on 2005 servers (because they improved the encryption). As we can't see the details of the objects on the 2005 server, we have to assume that any incoming object might be different to that object, which is why the migration script wants to migrate everything.
You might be able to work around this by finding out which objects you've changed (by seeing which ones are synchronized to your 2000 clone database) and only selecting those objects for synchronization. Other than that, I don't think there's a way to do what you want (because we just can't see what the state of the encrypted objects on the 2005 server is). / comments
The problem isn't that the database is on a remote server, but that the new target server is a 2005 server. Whilst we can get around the encryption on 2000 servers and retrieve details about the ob...
I've added your information to the bug report - we're pretty sure we know what the problem is (an assumption in our code that turns out not to be true for certain assemblies like System.Web) but it'll take quite a bit of work to fix and previously we only had one customer report. Now there are two reports, the fix is a bit higher up the priority stack, but I can't give any guarantees as to when it will find its way in. / comments
I've added your information to the bug report - we're pretty sure we know what the problem is (an assumption in our code that turns out not to be true for certain assemblies like System.Web) but it...
Is this error occurring when you register the databases or when you attempt to synchronize them? If it's the latter, then filtering out Assemblies and turning on the option 'Do not use ALTER ASSEMBLY to change CLR objects' might help.
If the error is occurring in a progress dialog box, we have a method of extracting the stack trace, which might shed more light on where the error is occurring - if you email me at michelle.taylor@red-gate.com I can set that up for you.
If you can provide a database backup of the troublesome database, or schema snapshots if you can create some which reproduce the problem, that would be fantastic, but we understand that not all of our customers can provide these things.
Unfortunately 'Index out of bounds in the array' is a very generic error message, and so it's quite hard to pin down where it might be occurring without a copy of your database to reproduce the error for ourselves - even the stack trace sometimes comes from the wrong thread, making it unreliable in pinning down the location of the error. / comments
Is this error occurring when you register the databases or when you attempt to synchronize them? If it's the latter, then filtering out Assemblies and turning on the option 'Do not use ALTER ASSEMB...
This sounds like a problem that happens when one of the SQL queries inside SQL Compare unexpectedly fails to return anything - we recently fixed a couple of these to do with interesting object names, but may not have got them all. Unfortunately it's quite difficult to tell which query is failing without further information. I don't suppose you could provide one or more of the following:
1) A Profiler trace taken during database registration, so we can work out which query is failing
2) Backups of two databases which are causing this problem, or schema snapshots (as it appears to be able to register them one at a time), so we can reproduce the problem ourselves
You can email any information you're willing to provide to michelle.taylor@red-gate.com and I will take a closer look at the problem. If I have an email address for you I can also send you a file which will let us get the stack trace of the exception if placed in the appropriate directory, which is sometimes helpful in tracking down these problems.
Thank you for reporting this problem; hopefully with a little more information we can get to the bottom of it and get a fix together. / comments
This sounds like a problem that happens when one of the SQL queries inside SQL Compare unexpectedly fails to return anything - we recently fixed a couple of these to do with interesting object name...