Comments
Sort by recent activity
Michelle: Your suggestion to use EMT.* results in anything with EMT in the name being excluded. I need for the objects that begin with EMT to be excluded. Do you have any other ideas?
David: You asked how we would like to specify the exclude filter for consideration in future releases. Ideally, what I would have liked to do is this:
/exclude:ALL:EMT.* in order to exclude all objects that start with EMT. / comments
Michelle: Your suggestion to use EMT.* results in anything with EMT in the name being excluded. I need for the objects that begin with EMT to be excluded. Do you have any other ideas?
David: Yo...
David --
Using "/exclude:ALL:EMT.*" works too good -- it removes all objects that have EMT anywhere in the name. I need to exclude only object that begin with EMT. Do you have any other ideas?
Thanks.
Abbe / comments
David --
Using "/exclude:ALL:EMT.*" works too good -- it removes all objects that have EMT anywhere in the name. I need to exclude only object that begin with EMT. Do you have any other ideas?
Th...
hi jonathan,
no, the developers do not existing on the target system because we do not grant any permissions to the developers on other environments. are you saying that they need to exist on the target systems?
i should have explained that we are using the command-line sqlcompare. we have not used the "ignorepermissons" option because we thought that exluding /users and roles would exlude the permissions - would simply using the option "ignorepermissons" solve this problem?
i don't know how to disable the include dependencies, using the command-line. should we be doing this?
thanks for your help.
mzcopea / comments
hi jonathan,
no, the developers do not existing on the target system because we do not grant any permissions to the developers on other environments. are you saying that they need to exist on the ...
here is our commandline script:
sqlcompare.exe /snapshot1:\d:\snap\namesnap.snp /server2:servername /database2:dbname /exclude:user /exclude:role /scriptfile:D:\scripts\Test\TestSynchronizationSql.sql /force /options:forcecolumnorder,ignorewhitespace
Thanks, Jonathan! / comments
here is our commandline script:
sqlcompare.exe /snapshot1:\d:\snap\namesnap.snp /server2:servername /database2:dbname /exclude:user /exclude:role /scriptfile:D:\scripts\Test\TestSynchronizationSql....
YES! Wonderful! My compare script went from 1.7 meg to 12KB. This will eliminate some of our build problems because the script would run into constraint issues unneccesarily due to attempting to make changes that were unneeded.
It's the little things that mean so much.
Thanks! / comments
YES! Wonderful! My compare script went from 1.7 meg to 12KB. This will eliminate some of our build problems because the script would run into constraint issues unneccesarily due to attempting ...
Is this normal behavior:
I did a sqlcompare between Snapshot1 and DB2 with only /exclude: user and /exclude:role and no other options. I applied that script to my DB2 successfully.
I then did a sqlcompare between Snapshot1 and DB2 and chose /include: table and added the /options forcecolumnorder and applied that script to DB2 successfully.
I then did a third script between Snapshot1 and DB2 which did a sqlcompare with /exclude: user and /exclude:role and I added the /forcecolumnorder option. I expected the snapshot and DB2 to be identical, but instead I got a huge script of differences and I get errors when I apply it due to some bad stored procedures which we need to fix.
BUT - If the forcecolumnorder option only forces table column order to be correct, why does sqlcompare detect additional differences in the third script? And I don't understand why the stored procedure problems weren't detected in the first script?
Thanks.
Abbe / comments
Is this normal behavior:
I did a sqlcompare between Snapshot1 and DB2 with only /exclude: user and /exclude:role and no other options. I applied that script to my DB2 successfully.
I then did a sq...
that's great, we'll give that a try.
one more thing - can we use sqlcompare.exe command-line to just apply a script without doing a compare first?
we'd like to create one script each week and use that same script for multiple environments. sometimes we tweak the script before we apply it. in order to do that, we need to be able to run sqlcompare.exe only to apply our final tweaked script.
thanks. / comments
that's great, we'll give that a try.
one more thing - can we use sqlcompare.exe command-line to just apply a script without doing a compare first?
we'd like to create one script each week and use t...
I thought I submitted a reply, but got knocked out of the forum, so I'll try again.
We have found that editing a stored proc in the editor in Sql Enterprise Manager (simply open the properties of the proc and edit there) will introduce the problem. Altering a stored proc with Query Analyzer can also introduce the problem. If you leave the stored proc there, it works fine, but if you copy the text to another place such as WordPad, the line feed will be missing wherever there was a missing ASCII10 in the proc. This is what is happening in our Sqlcompare scripts.
If you use Visual Studio to modify your stored procs, you won't have the problem. We are afraid to rely on that because we are a large IT shop with many developers and DB admins.
We have asked Microsoft to escalate our problem because we want to know if this is expected behavior.
It would be even better if Sqlcompare could deal with this. :-)
Microsoft Word actually fixes the problem - it will insert an ASCII10 wherever one is missing, so I guess it's possible.
Thanks. / comments
I thought I submitted a reply, but got knocked out of the forum, so I'll try again.
We have found that editing a stored proc in the editor in Sql Enterprise Manager (simply open the properties of t...
Another update:
Microsoft told us today that another customer has reported the same problem and they have entered the problem into their bug tracking system. They do not know yet whether a fix will be provided or not.
We have told our developers and db admins to use Visual Studio from now on. / comments
Another update:
Microsoft told us today that another customer has reported the same problem and they have entered the problem into their bug tracking system. They do not know yet whether a fix wil...
We are having the same problem with sql stored procs, particularly large procs. What we have discovered is that in the Sql Systable, there are missing ASCII 10's after the ASCII 13. This occurs randomly, or seems to. There doesn't appear to be a rhyme or reason. The missing ASCII 10's mess up the line feed and when Sqlcompare creates a script, code lines get placed directly behind comment lines in the destination stored proc. It works fine on the source stored proc.
We are already using Sql compare version 3.
We have talked to Microsoft and they claim that their stored procs are in Unicode and that the ASCII 10's are not needed for a carriage return/line feed. We can recreate the problem by copying the code into Wordpad (works fine in Notepad). They state that since the proc works fine on the source destination, it is not their problem. Since we are copying to a place that is non-Unicode, they cannot help us.
So - is Sqlcompare supposed to be able to deal with this? We use the command-line version to create our script.
If I need to explain further, please tell me what else you need to know. / comments
We are having the same problem with sql stored procs, particularly large procs. What we have discovered is that in the Sql Systable, there are missing ASCII 10's after the ASCII 13. This occurs r...