Activity overview
Latest activity by freecell1
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...
SQL Source Control wrongly detecting a 2008 db as 2014?
Two of our developers recently got new machines and are running SQL Server 2014, but everyone else has SQL Server 2008 R2. We are experiencing a strange phenomenon:
1) RedGateDatabaseInfo.xml in s...
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 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 ...
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.
SQL Prompt versus SSMS 2012 intellisense
Hi folks -
I just installed SSMS 2012. I've been using SQL PRompt 5 with SSMS 2008 R2 until now and like it. However in SSMS 2012 Microsoft seems to have improved the internal intellisense. Also...
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...
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...