How can we help you today? How can we help you today?
Gareth_B
Hi foobarred1, It sounds like the Static Data feature may be useful for you. Here's a link to the documentation for that: https://documentation.red-gate.com/disp ... tatic+data Is that helpful? / comments
Hi foobarred1, It sounds like the Static Data feature may be useful for you. Here's a link to the documentation for that: https://documentation.red-gate.com/disp ... tatic+data Is that helpful?
0 votes
Hi freecell1, thanks for your post. It seems that setting the compatibility level of a database doesn't change the database version that gets reported by SQL Server, just the behaviour of the database in question. Running SELECT @@VERSION on the database on your developers SQL 2014 instance should confirm this. In your case, I suspect the database is identifying itself as database version 12, although it's compatible with database version 10. One of our teams is currently working on improved identification of database versions & behaviour at the moment, which will hopefully yield a chance to report the compatibility level in the way you'd like. That will be a little way off though, so I'm afraid I'd have to suggest you continue with your workaround for the time being. If your developers commit frequently, it may be worthwhile trying to automate that fix-up step. Running a local script to update the RedGateDatabaseInfo.xml before commit could make it less of a pain, or you may be able to create an SVN pre-commit hook to reject commits with the wrong DatabaseVersion (therefore keeping your build safer). I think a pre-commit hook could automatically fix-up the DatabaseVersion for you, but that's not a recommended thing to do with SVN so I couldn't recommend it. / comments
Hi freecell1, thanks for your post. It seems that setting the compatibility level of a database doesn't change the database version that gets reported by SQL Server, just the behaviour of the datab...
0 votes