Comments
Sort by recent activity
Oleg wrote:
These objects are different in this version.
But they are equal
[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT ((0)),...
[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT (0),
These objects we are detecting as equal (more information about this topic is on http://blogs.red-gate.com/blogs/andras/). The double parantheses around certain default values is an architectural flaw in SQL Server 2005, but we compensate for it and compare constraints at a semantic level (as much as possible [image] ).
Regards,
Andras / comments
Oleg wrote:
These objects are different in this version.
But they are equal
[deleted] [int] NOT NULL CONSTRAINT [DF_nodes_deleted] DEFAULT ((0)),...
[deleted] [int] NOT NULL CONSTRAINT [DF_nodes...
obk wrote:
Instead I would like to have a feature in which I'm able to decide if I want one large script, or one script for each object.
Thanks in advance.
Hi,
unfortunatly in the cases of many objects (especially with Yukon ones) in order to modify a single object we need to do a lot of modification on other objects. For example to modify a single XML schema collection in certain cases one must drop and recreate message types, services, event notifications, functions, and unbind and then rebind to tables. If more than one object is involved the rebuild actions affect each other and it is almost impossible to separate the various actions from each other.
Regards,
Andras / comments
obk wrote:
Instead I would like to have a feature in which I'm able to decide if I want one large script, or one script for each object.
Thanks in advance.
Hi,
unfortunatly in the cases of man...
sleclair wrote:
Thanks, we do have three CLR procs in the database. They were initially created in pre-RTM Visual Studio but have been re-deployed using RTM Visual Studio.
Any guidance?
This is interesting. Would it be possible to have one of these assemblies? (Andras.Belokosztolszki "AT" red-gate.com). I have added support for some strange assemblies in our next beta (out soon) so hopefully it will also handle your case. If not please let me know.
Regards,
Andras / comments
sleclair wrote:
Thanks, we do have three CLR procs in the database. They were initially created in pre-RTM Visual Studio but have been re-deployed using RTM Visual Studio.
Any guidance?
This i...
sleclair wrote:
I have two SQL2005 databases that I'm trying to keep in synch. When I run sql compare 4, the compare process ends in an alert box with the Index out of bounds message.
To see which db had the offending object, I compared db1 to db1 successfully and then db2 to db2 successfully, however when I compare db1 to db2 or vice versa, I get the error.
I had been able to compare using the latest 3.x version of compare.
Please advise.
You most likely have an assemlby that is not following the ECMA standard. Please see the http://www.red-gate.com/messageboard/vi ... php?t=1462
Regards,
Andras / comments
sleclair wrote:
I have two SQL2005 databases that I'm trying to keep in synch. When I run sql compare 4, the compare process ends in an alert box with the Index out of bounds message.
To see whi...
LittleTinyMonkey wrote:
I recall this from version 3, and it seems to exist in version 4:
When ever I am performing a compare and I would like to ignore (or allow) any option, I feel that it would make sense to not highlight the options that i have chosen to ignore in the compare results window.
For example, if I have a table that has different identity seed values and different index names, if I choose to ignore identity seed and increment values for the compare, for the tables where identity seed values and index names are different, wouldn't it make sense to no longer highlight the line with the difference of identity seed values?
This isn't limited to the example I have provided, and perhaps there is a good reason to do it this way.......
Hi,
This is indeed a valid observation. With some options we handle this by not displaying ignored properties (e.g. extended properties, permissions, index padding, partition schemes). Similarly to whitespace insensitivity this is a clear situation from the difference visualisation point of view.
But in other cases our UI is considering only textual differences in the creation scripts, and shows ignored or semantically equivalent parts as different. We will consider your comment for later releases.
Regards,
Andras / comments
LittleTinyMonkey wrote:
I recall this from version 3, and it seems to exist in version 4:
When ever I am performing a compare and I would like to ignore (or allow) any option, I feel that it wou...
Hi Radovan,
this is rather interesting. Do I understand it right that you try to synchronize only this above stored procedure and the user is included as a dependent of this stored procedure? Could you check that the user is not explicitly selected for synchronization? Note that we create the user for that login if the user is selected explicitly or as a dependent (either as owner, or as a principal that has permissions on a particular object). The later can be surpressed by the "Ignore permissions" option.
Regards,
Andras / comments
Hi Radovan,
this is rather interesting. Do I understand it right that you try to synchronize only this above stored procedure and the user is included as a dependent of this stored procedure? Could...
mikea wrote:
OK, I used the "Ignore DML Triggers" option and the tables compared O.K.
However, I have a feature request. Let me be able to ignore the System Triggers like for replication, and compare the User defined triggers, otherwise, I cannot compare the triggers between my development and live machines.
Thanks,
Mike
Mike,
I'm happy that the option issue is sorted now. Also thank you for the feature request. For the next release we will not include it; however, the following dot release will contain an option to ignore replication triggers.
Regards,
Andras / comments
mikea wrote:
OK, I used the "Ignore DML Triggers" option and the tables compared O.K.
However, I have a feature request. Let me be able to ignore the System Triggers like for replication, and...
mikea wrote:
Andras wrote:
Mike,
are you sure you mean the Do not include plumbing for Transaction Sync? This option affects the synchronization script, and should not affect what differences are detected between databases. Also, could you tell me what differences show up for those tables? Many thanks,
Andras
The part that shows up as different is the triggers for replication of the tables, even though I have that option checked.
The "Do not include plumbing for Transaction Sync.." option has not much to do with triggers. Do you mean the "Ignore DML triggers" option? (the "Do not include plumbing for Transaction Sync" affects only synchronization and has no effect on comparison.
Regards,
Andras
Andras / comments
mikea wrote:
Andras wrote:
Mike,
are you sure you mean the Do not include plumbing for Transaction Sync? This option affects the synchronization script, and should not affect what differences...
mikea wrote:
This option does not seem to work. I have restored a production database that has replciation to my (local) machine, made changes, then compared.
In older versions, this would let met compare the tables and not have every table show up as being different. It does not work any more.
Mike,
are you sure you mean the "Do not include plumbing for Transaction Sync..." option? This option affects the synchronization script, and should not affect what differences are detected between databases. Also, could you tell me what differences show up for those tables? Many thanks,
Andras / comments
mikea wrote:
This option does not seem to work. I have restored a production database that has replciation to my (local) machine, made changes, then compared.
In older versions, this would let ...
EZLinks wrote:
I was attempting to synchronize two databases today and noticed that when an unexpected error occurs (such as an old stored procedure is encounted on the "from" database that includes references to a missing field on a table due to a sync from the other machine) the syncronization stops completely and does not allow the process to continue at all.
Is there a chance you can offer the ability to continue the sync and ignore the error rather than dying and having to manually track down changes to the DB?
Here is an example of the error that caused a stop: The following error message was returned from the SQL Server:
[207] Invalid column name 'BeginDate'.
Invalid column name 'EndDate'.
Hi,
one thing you can try is to exclude this stored procedure only, and disable include dependencies. This will work only in this case, and if there are other corrupt stored procedures in your database, SQL Server once again will not allow you to run the script. Another alternative is to set the "Do not include plumbing for transactional synchronization scripts". Then run the script from a query analyzer. This will not use transactions, just simple batch separators.
The reason we do not skip errors is that if SQL Server does not accept a stored procedure because it is in an inconsistent state (while missing table references are ok, references to nonexisting columns in existing tables are not ? [image] ) dependent objects cannot be synchronized either, and the target database would most likely end up in a bigger mess.
Note also, that while many stored procedures were accepted by SQL Server 2000, 2005 has a much better syntax checker, picks out more inconsistencies, and rejects procs that were valid previously.
Regards,
Andras / comments
EZLinks wrote:
I was attempting to synchronize two databases today and noticed that when an unexpected error occurs (such as an old stored procedure is encounted on the "from" database that incl...