How can we help you today? How can we help you today?
isme
In the end I worked around the limitation by replacing the project file with lots of command-line switches and other tools. I used TortoiseSVN's command-line svn client to export the database schema from the repository, and then used SQLCompare.exe to compare the script directory to the target database and exclude the unwanted objects. The commands look like this: svn export http://svn.cloudcorp.com/database/trunk/GeoDB GeoDB SQLCompare /scr1:GeoDB /server2:LOGSERVER /database2:GeoDB /exclude:All:sp_MS* /exclude:Schema:offline_* The output of SQLCompare.exe now shows that the schemas are identical: SQL Compare: activated, edition: professional, serial number: REDACTED SQL Compare Command Line V10.4.8.87 ============================================================================================== Copyright © Red Gate Software Ltd 1999-2013 Registering data sources Creating mappings Comparing Applying Command Line Items Retrieving migration scripts Checking for identical databases Error: The selected objects are identical or no objects have been selected in the comparison. It's surprising and a little frustrating that SQLCompare.exe does not parse all the data in the project file. It means I can't use the project file to drive scripted deployments in my multi-server environment. Is there a possibility that the behavior of the command-line version will be upgraded to match that of GUI version? / comments
In the end I worked around the limitation by replacing the project file with lots of command-line switches and other tools. I used TortoiseSVN's command-line svn client to export the database schem...
0 votes
Also ignore my second comment. I misread the SSMS script. I just realized that IGNORE_DUP_KEY = OFF is the default setting. Never mind! Thanks for your help, Brian! / comments
Also ignore my second comment. I misread the SSMS script. I just realized that IGNORE_DUP_KEY = OFF is the default setting. Never mind! Thanks for your help, Brian!
0 votes
You can use Red Gate's SQL Source Control plugin for Management Studio to fix this: 1) Remove (svn delete) the static data file from version control. 2) In Object Explorer, right-click on the table containing the static data, and choose 'Other SQL Source Control Tasks', and then 'Link/Unlink Static Data'. [image] 3) A list of tables should appear with a check next to your static data table. Click 'Save and Close'. [image] If no check mark appears, you may have to add a primary key to the table first. 4) Go to the main SQL Source Control tab and view the Commit Changes tab. Commit the new 'Data Link' change type to check in the static data. [image] After the commit succeeds, your data will be under version control as before. Additionally, changes to the data will be automatically detected by SQL Source Control and it will prompt you to commit these data changes. And, of course, SQL Source control will no longer issue 'Non-schema statement was ignored' warnings! At the SQL In The City conference in London last month, I had the opportunity to discuss this directly with one of the developers. He explained that the data file set is defined not by the content of the Data directory alone but also by the <DataFileSet> section of the file RedGateDatabaseInfo.xml. Any file in the Data directory not also listed in this XML file will be parsed as a schema file instead of a data file. Thanks for your help, Red Gate! / comments
You can use Red Gate's SQL Source Control plugin for Management Studio to fix this: 1) Remove (svn delete) the static data file from version control. 2) In Object Explorer, right-click on the table...
0 votes