Comments
Sort by recent activity
grchristin wrote:
We changed the names of a couple of tables in our DB. When trying to synchronize our development DB to our test production DB we received errors that it couldn't create some constraints because they already existed and rolled back any changes. I had to manually rename the tables, re-run the compare and then run the synchronization. It then worked. Bug? Should SQL Compare 4 be able to handle it?
Hi,
Constraint names must be unique in the database. This is an ugly limitation of SQL Server, especially since constraints can only be accessed via their parent tables. You are right that we are not handling such conflicts. On the other hand it is an interesting question about how we should handle it. Clearly we cannot just drop constraints from tables that were not selected for synchronization. Similarly we should not move constraints to other tables. One thing SQL Compare can do, is that if the renamed table is selected, it can drop it/or resolve the constraint problem by making it the same as the source table (if there is any). Therefore these conflicts require manual intervention. A similar problem occurs when one tries to migrate a table (say "herTable") to another database, but that database already has another non-table object (e.g. a function) called "herTable". Once again the only solution that can be used from SQL Compare would be to explicitly select the "herTable" function as well, in which case it will be dropped as expected, and the synchronization will succeed. But, clearly, we cannot select objects to be deleted automatically.
Regards,
Andras / comments
grchristin wrote:
We changed the names of a couple of tables in our DB. When trying to synchronize our development DB to our test production DB we received errors that it couldn't create some c...
HLEBOEUF wrote:
I'm using 2005 and yes, you're right i'm using linked servers in my stored procedures.
Will they be a way the SqlCompare product will work arround it ?
Because it dosn't make big sense when i'm not able to synchronize all objects.
Unfortunately this is a limitation of SQL Server. You could try one of the following. You could try to lower the transaction isolation level in the script generated by SQL Server. In the generated script we use serializable. If you change this to read commited, it might help (it relaxes the requirements for the distributed transaction). So you need to include:
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
Another alternative is that if you are confident that the transaction will succeed, and there are no strange dependency problems, you may use the NoPlumbing option in SQL Compare's options. Note, that when this option is selected, the synchronization is not executed in a transaction, thus rollback does not work.
Regards,
Andras / comments
HLEBOEUF wrote:
I'm using 2005 and yes, you're right i'm using linked servers in my stored procedures.
Will they be a way the SqlCompare product will work arround it ?
Because it dosn't make big...
HLEBOEUF wrote:
In the first comparison i'm making between 2 databases i'm getting an error [3910] Transaction context in use by another session when synchronizing.
Any suggestion on how to get it working.
Harry Leboeuf
Hi,
are you using SQL Server 2000 or 2005? What I suspect the problem is that you have a linked server which is referred to in one of your database objects. In this case the transaction produced by SQL Compare is upgraded to a distributed transaction. SQL Server 2005 is much stricter about these, and accepts less. Were you able to find which object is causing the problem?
Andras / comments
HLEBOEUF wrote:
In the first comparison i'm making between 2 databases i'm getting an error [3910] Transaction context in use by another session when synchronizing.
Any suggestion on how to get ...
Brian Donahue wrote:
Hello there,
Yes, but I think it really should work anyway. I'll get someone to look into it.
Hi,
many thanks for letting us know about this issue. It indeed affects compatibility mode 80 on 2005.
Regards,
Andras / comments
Brian Donahue wrote:
Hello there,
Yes, but I think it really should work anyway. I'll get someone to look into it.
Hi,
many thanks for letting us know about this issue. It indeed affects compa...
Just a short followup. This bug only affects REFERENCES and EXECUTE permissions on user defined types that are migrated from 2005 to 2000.
Regards,
Andras / comments
Just a short followup. This bug only affects REFERENCES and EXECUTE permissions on user defined types that are migrated from 2005 to 2000.
Regards,
Andras
monty wrote:
Hi,
We have a custom type 'boolean' in our databases and after comparing two databases (one on SQL 2005 express and the other on SQL 2000), the custom type has been considered to be different.
However, when I go to update the database in the SQL 2000 server, I get the following error message:
The following error message was returned from the SQL Server:
[170] Line 1: Incorrect syntax near 'TYPE:'.
The following SQL command caused the error:
GRANT REFERENCES ON TYPE:: [dbo].[boolean] TO [public]
IF EXISTS (SELECT * FROM #tmpErrors) ROLLBACK TRANSACTION
It appears that the only difference between the type in one db to the other is that the permissions are different.
Any suggestions?
Using SQLExpress 4.1.0.59
thanks
Mark
Hi Mark,
many thanks for your feedback. It is indeed a bug in SQL Compare which we will fix shortly. Meantime, you could either set the ignore permissions option, or you will need to remove the permission alter lines for user defined types from the script manually.
Regards,
Andras / comments
monty wrote:
Hi,
We have a custom type 'boolean' in our databases and after comparing two databases (one on SQL 2005 express and the other on SQL 2000), the custom type has been considered to be...
vivus wrote:
will the new 4.0 beta support Syncing with user instances and attachDBFile?
is there an rss feed or email list when the new 4.0 is released and will it be compatible with the 2.0 framework?
Deepest Regards,
Michael
Hi Michael,
I was in the belief that the current beta works both with user instances and with attachDBFile. If it is not so, could you give me more information about it.
To answer your other question, the current beta and the release are compatible with .Net 2.0. Concerning the email list on which you can get notifications someone will get back to you soon.
Regards,
Andras / comments
vivus wrote:
will the new 4.0 beta support Syncing with user instances and attachDBFile?
is there an rss feed or email list when the new 4.0 is released and will it be compatible with the 2.0 fr...
dscotland wrote:
I am also having problems synchronising extended properties the probelm appears to be that sql compare is substituting USER where it should in fact be SCHEMA
e.g.
SQL compare produces
sp_addextendedproperty N'Description', N'Updates an existing user in the Users table.', 'USER', N'Requests', 'PROCEDURE', N'updateUser', NULL, NULL
but this should be
sp_addextendedproperty N'Description', N'Updates an existing user in the Users table.', 'SCHEMA', N'Requests', 'PROCEDURE', N'updateUser', NULL, NULL
Regards
David
Many thanks for your report, I'll fix it soon.
Regards,
Andras / comments
dscotland wrote:
I am also having problems synchronising extended properties the probelm appears to be that sql compare is substituting USER where it should in fact be SCHEMA
e.g.
SQL compare pr...
Oleg wrote:
I do synchronization, refresh and the same objects are different again.
Difference is in whitespaces. But as for me after sync objects must be equal.
Hi Oleg,
as Jon mentioned there is an issue with tailing newlines when migrating from 2000 to 2005. This is because of the way 2005 "eats" some newlines. At the moment the only way around it is to set "ignore whitespace" to on, but we are looking into this bug. Note that 2000 to 2000 migration, as well as 2005 to 2005 migration should work.
Regards,
Andras / comments
Oleg wrote:
I do synchronization, refresh and the same objects are different again.
Difference is in whitespaces. But as for me after sync objects must be equal.
Hi Oleg,
as Jon mentioned ther...
monty wrote:
Hi Andras,
According to the blog entry you mentioned in your last post on this topic, the comparing of the default values has been taken care of, however, I'm still getting differences being displayed in SQL Compare.
eg
Server1 (SQL Server Express 2005 (9.0.1399))
[ContractFactor] [float] NULL DEFAULT ((0.0))
Server 2 (SQL Server 8.0.194)
[ContractFactor] [float] NULL DEFAULT (0.0)
Is this just a problem that can't be solved, or is there a setting somewhere that does this (I can't seem to see one)??
thanks
Mark
Hi Mark,
Brian is right that these defaults cannot be reproduced the same way on a target database. This is a SQL Server limitation. And this is the reason why we compare them at semantic level. If this is the only difference between two tables we should mark them as being equal. Note, that in the bottom panel we display textual differences, so there the different rows are marked as different. I have created a table with the above column specification, and as expected the tables were marked equals, but the bottom panel (that shows the scripts) a textual difference is shown.
Please let me know if you are experiencing a different behaviour. I would also appreciate if you could tell me what non default options you are using.
Regards,
Andras / comments
monty wrote:
Hi Andras,
According to the blog entry you mentioned in your last post on this topic, the comparing of the default values has been taken care of, however, I'm still getting differen...