Comments
Sort by recent activity
Some more information - I believe that just as the UI for SSC doesn't show versions prior to the branch for migration scripts, that they similarly aren't considered when looking for migration scripts to apply. It seems that as far as SQL Compare (v10.1) is concerned, these revisions don't exist in the branch. Could this be the case? / comments
Some more information - I believe that just as the UI for SSC doesn't show versions prior to the branch for migration scripts, that they similarly aren't considered when looking for migration scrip...
Solved it - it appears that without the 'Default' option included, the 'sp_refreshview' calls are never included (at least for me on 10.1). So my new set of options is:
Default,ie,iq,nt,iu,ip,nc
and everything is working. This should have been equivalent to:
if,ifg,iw,ie,iq,nt,iu,iup,ip,nc,incd
shouldn't it? This set was only missing 'DecryptPost2KEncryptedObjects', 'IgnoreWithElementOrder' and 'IgnoreDatabaseAndServerName' but none of those should have affected the dependencies I would think. Is there something undocumented in the 'Default' option? / comments
Solved it - it appears that without the 'Default' option included, the 'sp_refreshview' calls are never included (at least for me on 10.1). So my new set of options is:
Default,ie,iq,nt,iu,ip,nc
an...
I read that part (which is how I deduced the options from default I was missing), but as I mentioned, these missing options shouldn't have caused the omission of sp_refreshview or constraints handling. Is there any reason why the default option would be required in order to get this to work? Could it be specific to comparing source control to scripts and / or with migration scripts enabled? / comments
I read that part (which is how I deduced the options from default I was missing), but as I mentioned, these missing options shouldn't have caused the omission of sp_refreshview or constraints handl...
Hi Brian,
Thanks for the reply, but as I mentioned, I've already tried the 'incd' option, which appears to do the reverse - updates only objects that the current object is dependent on (e.g. function depends on a view), rather than the other way - update the objects that depend on the current object (e.g. views that depend on a table), which I want.
Could this have something to do with migration scripts? Have you tested using the exact command line parameter set? I've found that they do seem to interact somewhat in expected ways when used differently from the norm. / comments
Hi Brian,
Thanks for the reply, but as I mentioned, I've already tried the 'incd' option, which appears to do the reverse - updates only objects that the current object is dependent on (e.g. functi...
Here it is:
"C:\Program Files (x86)\Red Gate\SQL Compare 10\SQLCompare.exe" /sourcecontrol1 /revision1:Latest /scriptsfolderxml:"%teamcity.build.checkoutDir%\Build\compare.xml" /migrationfolderxml:"%teamcity.build.checkoutDir%\Build\migration.xml"
/scripts2:"%teamcity.build.checkoutDir%\sourcedb" /options:if,ifg,iw,ie,iq,nt,iu,iup,ip,nc /scriptfile:"%teamcity.build.checkoutDir%\Build\Scripts\%Version%b.sql"
Where %Version% = 4.0.0 (at the moment), check out dir is agent-side default check out dir and the sourcedb folder is the source-controlled (SQL Source Control) schema folder for the version to compare against (couldn't see how to supply 'scriptsfolderxml' for the second source control).
Compare.xml
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<!--
SQL Compare 10
SQL Compare
Version:10.1.0.102-->
<ISOCCompareLocation version="1" type="SvnLocation">
<RepositoryUrl>http://[removed]/trunk/database/Schema/</RepositoryUrl>
</ISOCCompareLocation>
Migration.xml
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<!--
SQL Compare 10
SQL Compare
Version:10.1.0.102-->
<ISOCCompareLocation version="1" type="SvnLocation">
<RepositoryUrl>http://[removed]/trunk/database/Migration Scripts/</RepositoryUrl>
</ISOCCompareLocation> / comments
Here it is:
"C:\Program Files (x86)\Red Gate\SQL Compare 10\SQLCompare.exe" /sourcecontrol1 /revision1:Latest /scriptsfolderxml:"%teamcity.build.checkoutDir%\Build\compare.xml" /migrationfolderxml:...
Scratch that - it seems that unless you use source control as the source for the database, migration scripts are ignored (even though it actually says it is retrieving them in the output). However, there's good news: I finally got it to work. Here's what I did:
Created a project in the SQL Compare UI, specifying source control as the source (not using scripts), mirroring exactly what I was doing in the command line.
Created a deployment script.
Saved the project.
Opened the project file (in '[documents]\SQL Compare\SharedProjects') in a text editor.
Copied the contents of the 'ScriptFolderLocation' and 'MigrationsFolderLocation' elements to separate XML files, replacing '<' and '>' with '<' and '>' respectively and saving in UCS-2 Little Endian (using Notepad++) - this is required due to the UTF-16 in the header.
Specified the above XML files as the '/scriptsfolderxml' and '/migrationfolderxml' parameters, along with '/sourcecontrol1' parameter (no value despite what command line help says), '/revision1:Latest' and all my other usual parameters (except '/scripts1' of course).
And it worked (migration script finally included). I'm not sure if registering the source control in SQL Compare (as part of creating the project), actually running the comparison, creating the deployment script, or getting those two XML files exactly right is what fixed it, but I no longer get an 'object reference' error (due to one or more of these).[/list] / comments
Scratch that - it seems that unless you use source control as the source for the database, migration scripts are ignored (even though it actually says it is retrieving them in the output). However,...
It seems the 'scriptsfolderxml' must always be provided, even if you don't need it (e.g. if you're using '/scripts1'), so just add '/scriptsfolderxml:"blank"' (without the single quotes) and it seems to work. The 'blank' can be anything (other than nothing, or it errors) - must be a bug. / comments
It seems the 'scriptsfolderxml' must always be provided, even if you don't need it (e.g. if you're using '/scripts1'), so just add '/scriptsfolderxml:"blank"' (without the single quotes) and it see...
Will SQL Source Control be re-built against Subversion 1.7 in order to use the more efficient HTTP v2 protocol and next generation working copy for better performance? / comments
Will SQL Source Control be re-built against Subversion 1.7 in order to use the more efficient HTTP v2 protocol and next generation working copy for better performance?