Re: Managing application and database version dependencies
It is also worthwhile to check the environment at the same time, I have a flag for development test and production, you do not want to run tests against your production database! On Fri, May 7, 2010 at 3:06 PM, David Richards ausdot...@davidsuniverse.com wrote: I have a Version table that has a single column, single row with a version number in the form A.B.C.D. I started doing this to follow the same version standard as my apps. So the number would be: A - Breaking change B - Non breaking change (eg additional table, additional column with default) C - No interface change (eg an index) D - only included to have the same format In practice though, pretty much every change I've ever had to make has been a breaking change so a single number would have been just as good. I still use the format though, just for the sake of being standardised. David If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate! -Zapp Brannigan, Futurama On Fri, May 7, 2010 at 14:24, Greg Keogh g...@mira.net wrote: Matt, I like to put two magic numbers in a special database table: The change number, The compatibility number. The first increments whenever the schema changes. The second increments only when a “breaking” change is made. The app startup code can use these numbers to determine if it can run or not, or perhaps to run in a crippled way (but I haven’t needed that yet). Your needs are probably far more complicated that I describe, but my tiny humble system at least forces you to think about keeping the code and DB working together. Greg
Managing application and database version dependencies
Hi Folks, We have a product comprised of desktop apps (.NET and native) that talk to SQL Server 2008. The database and apps get installed at client sites that we have no ongoing control over. We use a table in the database to track schema versions and our database creation / upgrade script uses this to migrate the schema from one version to the next. The data is mostly accessed and modified through stored procedures as we have to manage both native and .NET code. From our apps we can check the schema version to ensure that the database is compatible with the app, but I'd also like to deal with the scenario where the database is upgraded such that it breaks compatibility with existing apps. I'm thinking that the database needs to store a minimum version number for such apps, then when the app connects it can check if its version is lower than the database requires and exit. I'm interested to know if / how others handle this scenario. Cheers, Matt.
RE: Managing application and database version dependencies
Matt, I like to put two magic numbers in a special database table: The change number, The compatibility number. The first increments whenever the schema changes. The second increments only when a breaking change is made. The app startup code can use these numbers to determine if it can run or not, or perhaps to run in a crippled way (but I haven't needed that yet). Your needs are probably far more complicated that I describe, but my tiny humble system at least forces you to think about keeping the code and DB working together. Greg
Re: Managing application and database version dependencies
As soon as I read 'compatibility number' in your email I remembered we discussed this internally long ago. Just recently I was thinking of tracking the required version for each app that connects to the database but after thinking about it I don't think we'll need that level of granularity. A single compatibility number kind of forces us to keep all the apps in line, and I think there's some benefit to that as it would help to avoid scenarios where we have a mix of several different app versions trying to work together. Thanks! On Fri, May 7, 2010 at 2:24 PM, Greg Keogh g...@mira.net wrote: Matt, I like to put two magic numbers in a special database table: The change number, The compatibility number. The first increments whenever the schema changes. The second increments only when a “breaking” change is made. The app startup code can use these numbers to determine if it can run or not, or perhaps to run in a crippled way (but I haven’t needed that yet). Your needs are probably far more complicated that I describe, but my tiny humble system at least forces you to think about keeping the code and DB working together. Greg
Re: Managing application and database version dependencies
I have a Version table that has a single column, single row with a version number in the form A.B.C.D. I started doing this to follow the same version standard as my apps. So the number would be: A - Breaking change B - Non breaking change (eg additional table, additional column with default) C - No interface change (eg an index) D - only included to have the same format In practice though, pretty much every change I've ever had to make has been a breaking change so a single number would have been just as good. I still use the format though, just for the sake of being standardised. David If we can hit that bullseye, the rest of the dominoes will fall like a house of cards... checkmate! -Zapp Brannigan, Futurama On Fri, May 7, 2010 at 14:24, Greg Keogh g...@mira.net wrote: Matt, I like to put two magic numbers in a special database table: The change number, The compatibility number. The first increments whenever the schema changes. The second increments only when a “breaking” change is made. The app startup code can use these numbers to determine if it can run or not, or perhaps to run in a crippled way (but I haven’t needed that yet). Your needs are probably far more complicated that I describe, but my tiny humble system at least forces you to think about keeping the code and DB working together. Greg
