Comments
Sort by recent activity
Chris, thanks for your reply.
I did not include "default" in my options switch, and am using /exclude:User. My full command is:
SQLCompare.exe /project:"<project.scp>" /exclude:User /exclude:Role /exclude:Schema /AllowIdenticalDatabases /options:IgnoreNotForReplication,IgnoreReplicationTriggers,IgnoreUserProperties,IgnoreUsers,IgnoreWhiteSpace,IgnorePermissions,ForceColumnOrder,IgnoreFileGroups /out:"<myoutfile.txt>" /f /verbose /report:"<myreport.html>" /reporttype:Interactive /scriptfile:"<myscriptfile.sql>"
Is there something I am missing? / comments
Chris, thanks for your reply.
I did not include "default" in my options switch, and am using /exclude:User. My full command is:
SQLCompare.exe /project:"<project.scp>" /exclude:User /exclude:Role /...
In my specific case, I need to compare a database (SQL 2000) that is publishing transactional replication data to a database (SQL 2000 and 2005) that is not subscribing to any replication. Ideally, I would be able to exclude the msrepl_tran_version column, as this does not need to be moved to any databases not acting as replication publishers.
I believe SQL 2005 creates stored procedures that execute updates for replication (instead of adding a field to each table). These are prefaced with "sp_", and end in the table needing to be updated. A method to categorically exclude these stored procedures from a comparison would also be helpful. / comments
In my specific case, I need to compare a database (SQL 2000) that is publishing transactional replication data to a database (SQL 2000 and 2005) that is not subscribing to any replication. Ideally,...
Not to jump in late on this, but...
Having the ability to ignore msrepl_tran_version columns and other replication artifacts would be outstanding! Thanks for address this! / comments
Not to jump in late on this, but...
Having the ability to ignore msrepl_tran_version columns and other replication artifacts would be outstanding! Thanks for address this!
I set the compare to trim trailing spaces. However, the same error remains.
There are 9 records in the table I am attempting to script. The first 8 records do not use UPDATETEXT in the script, and they run just fine. However, the last record has a text field that is significantly longer than the others (i.e. there is more actual text in the field). This record is the one causing the script to fail.
As it is a text field, I cannot do a LEN(field) to find the length. If I convert the column to a VARCHAR(8000), the length returns 8000. I suspect the text field is actually longer than that, but max VARCHAR length is 8000.
Thanks for all your help, Brian. / comments
I set the compare to trim trailing spaces. However, the same error remains.
There are 9 records in the table I am attempting to script. The first 8 records do not use UPDATETEXT in the script, and ...
The columns in both databases are the same; I used SQL Compare to script the table creation. The text is basically an XML document, and there are no special characters in the suspect statements.
The SQL statements that fail look something like: EXEC(N'DECLARE @pv binary(16)
'+N'SELECT @pv=TEXTPTR([XmlDocument]) FROM [dbo].[XchangeStandard] WHERE [XchangeStandardId]=9
UPDATETEXT [dbo].[XchangeStandard].[XmlDocument] @pv NULL NULL N''
whereas statements updating the same table that appear to work are basic INSERT INTO statements (i.e.
INSERT INTO [dbo].[XchangeStandard] ([XchangeStandardId], [Version], [XmlDocument], [Type]) VALUES (9, ...
It seems as if a single record is being split into two different statements for some reason: an INSERT INTO and an EXEC('INSERT INTO...). Hopefully that makes at least a little sense? :? / comments
The columns in both databases are the same; I used SQL Compare to script the table creation. The text is basically an XML document, and there are no special characters in the suspect statements.
Th...
A correction (since I can't edit the original post):
In DC 5, the compare results in 3 tables that do not compare properly, and I need to manually set the key to get them to compare, after which the compare works fine (until I run the SQL script, that is).
In DC 4, these 3 tables do not even show up in the compare, and there is no option that I know of to manually set the key, as in DC 5. So, the compare with DC 4 works because it doesn't script the problem table at all, and thus the SQL script has no errors.
My assertion that the script works under DC4 but not DC5 is technically correct, but very misleading, so please disregard. / comments
A correction (since I can't edit the original post):
In DC 5, the compare results in 3 tables that do not compare properly, and I need to manually set the key to get them to compare, after which th...
Oops, forgot to include the link to the MS article. Check it out here. / comments
Oops, forgot to include the link to the MS article. Check it out here.
Tom,
I am using DC 5.1.0.106, and I am seeing this same issue. When running a compare, the same FK constraint was in the SQL script 3 times, both for the DROP and the ADD. This only happened for one constraint, though; the rest of the FKs appeared to script just fine. / comments
Tom,
I am using DC 5.1.0.106, and I am seeing this same issue. When running a compare, the same FK constraint was in the SQL script 3 times, both for the DROP and the ADD. This only happened for on...