Comments
Sort by recent activity
Hi Gareth -
I might be misunderstanding the use of DatabaseVersion.
SELECT @@VERSION
gives the SQL Server version while
SELECT compatibility_level
FROM sys.databases WHERE name = 'MyDatabase';
@version gives a result like "Microsoft SQL Server 2008 R2 (SP1) - 10.50.2550.0 (X64) Jun 11 2012 16:41:53 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)" but the Redgate XML is storing values like 10 or 12 which look like db compat versions.
In the meantime, I am going to upgrade the Redgate tools on the build server so they recognize db version 12 - it's possible this will be sufficient for our needs.
Thanks,
John / comments
Hi Gareth -
I might be misunderstanding the use of DatabaseVersion.
SELECT @@VERSION
gives the SQL Server version while
SELECT compatibility_level
FROM sys.databases WHERE name = 'MyDatabase';
@ve...
I also just had the same problem and found this thread. The issue is in fact that I upgraded my local SSC to 3.8 and we have some scripts with no comments. Steps to reproduce:
1) Upgrade to SSC 3.8
2) Go to Commit Changes tab on a database that has some migration scripts with no comments.
3) SSC prompts you to commit but shows no changes in the compare window.
4) Try to commit.
5) Error - Nothing To Commit.
Here's how to easily resolve. I was unable to add a comment in the SSC UI using Edit Scripts on old scripts, so:
1) In your local svn working folder, find the .migrationScript files in question (your main checkout folder, not the working base folders that SSC makes in your user profile).
2) In a text editor amend the files as follows. Replace:
</ObjectIdentifiers>
</MigrationScript>
with
</ObjectIdentifiers>
<Description>Dummy retroactive comment to handle SSC 3.8 bug.</Description>
</MigrationScript>
3) Commit using TortoiseSVN if you use that, or just the svn client.
4) Go back to SSMS / SSC and refresh the Commit Changes tab.
5) You shouldn't see any changes. Voila!
6) Yell at developers for committing scripts with no comments! / comments
I also just had the same problem and found this thread. The issue is in fact that I upgraded my local SSC to 3.8 and we have some scripts with no comments. Steps to reproduce:
1) Upgrade to SSC 3...
I had the same thing just happen to me except it was when the last (and only) object was a function. I was able to work around it by adding a bogus statement after the alter function part: -- this was the END from the alter function section
END
-- this was getting omitted.
GO
-- non-update to a random table
UPDATE dbo.SearchParameter
SET DisplayName = DisplayName
WHERE 1 = 0;
-- this GO still got omitted but for some reason things worked.
GO
/ comments
I had the same thing just happen to me except it was when the last (and only) object was a function. I was able to work around it by adding a bogus statement after the alter function part:-- this ...
Thanks Chris. Turning off auto-list members on SSMS options fixed my problem. / comments
Thanks Chris. Turning off auto-list members on SSMS options fixed my problem.
We are having a similar problem with case and our SQL Server is indeed set to case insensitive collation (SQL_Latin1_General_CP1_CI_AS).
This is the SQL Server default. You can check it by:
SELECT name, collation_name
FROM sys.databases
WHERE name = 'mydatabase'
It would be nice if there were a workaround. We recently had an effort where we changed the strings on our client's site to be mixed case (they are stored in the db). We have spent a number of days trying to deal with the inability to actually cause changes to be rolled out to other machines via SSC.
The funny thing is that in the script files in subversion, the casing is correct. That is, I can change the case locally and also another field like a datestamp and SSC will take the commit. However when another developer gets latest, it gives them the updated date but not the updated string.
There must be a fix for this ... it's also confusing because the comparison pane on the commit changes screen shows the strings as different (i.e. it's showing a case sensitive comparison).
Is it a bug perhaps? / comments
We are having a similar problem with case and our SQL Server is indeed set to case insensitive collation (SQL_Latin1_General_CP1_CI_AS).
This is the SQL Server default. You can check it by:
SELECT...
Version: Red Gate SQL Data Compare Command Line Utility V10.0.1.119
Thanks for creating the case. The compare is still not working correctly, although I did get the errors to stop. The syntax that worked better was using two XML tags (middle example above), but I added a RegEx end-of-line match to stop the error:
<excludecolumns>ResourceStringValue:DateModified</excludecolumns>
<excludecolumns>Site$:Domain</excludecolumns>
Without the $, I was getting an error like "no column 'Domain' in table SiteDisplayListItem". I have other tables whose names start with "Site" and the matches are treated as LIKE matches.
So the error code is fixed; however, the comparison still returns differences even if the excluded Domain column is the only one with changes.
Hope to figure this out ... / comments
Version: Red Gate SQL Data Compare Command Line Utility V10.0.1.119
Thanks for creating the case. The compare is still not working correctly, although I did get the errors to stop. The syntax t...
I just had this issue using SSC 3.7. Someone reordered the columns in a table and also edited the trigger in the same commit. No migration script. After that, no one else could get latest.
As a workaround, just having the other developers unlink and relink the database solved the problem. / comments
I just had this issue using SSC 3.7. Someone reordered the columns in a table and also edited the trigger in the same commit. No migration script. After that, no one else could get latest.
As a ...
Any update on this? I posted in another thread about this (for varchar, not XML). Ideally even on case insensitive collated databases, changed-case string could be committed and transferred to other devs via SSC. I've even tried tricking it by updating a second field (like a datestamp). The behavior is that the other dev gets the new date value but the string value is left unchanged.
But the INSERT statements stored in the static data script in svn are picking up the correct case. / comments
Any update on this? I posted in another thread about this (for varchar, not XML). Ideally even on case insensitive collated databases, changed-case string could be committed and transferred to ot...
Here are the property values from my local box (linked to svn) and the dev server we push to:
Local:
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<ISOCCompareLocation version="1" type="SvnLocation">
<RepositoryUrl>http://tco-dev-scm.xxx.internal/svn/code/trunk/Database/MigrationScripts/Intranet/</RepositoryUrl>
</ISOCCompareLocation>
Dev:
<?xml version="1.0" encoding="utf-16" standalone="yes"?> <ISOCCompareLocation version="1" type="SvnLocation"> <RepositoryUrl>http://tco-dev-scm.xxx.internal/svn/code/trunk/Database/MigrationScripts/Intranet/</RepositoryUrl> </ISOCCompareLocation>
They seem the same. Is it possible the way I call the command line, or the exclude filters, is causing a problem? Here are the command line params:
/exclude:role /exclude:user /exclude:assembly /sourcecontrol1 /Server2:TCO-DEV-SQL-02 /Database2:Intranet /sync /migrationfolder:C:\TeamCity\buildAgent\work\946b3977434c5179\database\migrationscripts\Intranet /scriptsfolderxml:C:\TeamCity\buildAgent\work\946b3977434c5179\Build\Shared\config\SQLCompareSvnConfig_Intranet_temp.xml /revision1:HEAD /versionusername1:builduser /versionpassword1:xxx
Thanks,
John / comments
Here are the property values from my local box (linked to svn) and the dev server we push to:
Local:
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<ISOCCompareLocation version="1" type="...
It's similar actually. I have a support case open but we seem to be stuck. What happens is:
1) I choose to compare subversion HEAD to a shared database server.
2) The comparison results screen correctly shows objects that changed since the last sync with that server. In my case subversion is at 5034 and the dev SQL server is at 5018. The database extended property on the SQL server shows 5018.
3) But ... once I click Deployment Wizard, the "Review Migration Scripts" page shows pre-selected migration scripts from earlier revision. Also, the little circle-graph at the bottom says "The deployment script will be created as follows: 0 --> 4673 --> 4783 --> 5018 --> 5034" and if I click Next, it generates a script with all the old, unneeded changes.
If I uncheck the older migration scripts, it still scripts back to rev 0, just without the scripts.
It seem obvious that it's not "getting" that the target server is on rev 5018. There are no RedGate tools on the target SQL Server, but I'm not aware that they need to be there.
Any clues are appreciated ... I ma y be missing something obvious.
John / comments
It's similar actually. I have a support case open but we seem to be stuck. What happens is:
1) I choose to compare subversion HEAD to a shared database server.
2) The comparison results screen co...