I've just come across the fact that the next version of SQL Server (Denali) will not run on Windows XP. At first, I was a little shocked but I guess it shouldn't be a surprise. After all, lest we forget that XP is now the n-2 version of Windows.
I suppose its a credit to Microsoft that Windows XP is in still in such widespread use and its quality has meant that a lot of companies are reluctant to upgrade, particularly with the issues surround Vista.
Personally though, it doesn't bother me that MS won't be supporting Denali on XP as typically I would be running the software on a Server OS such as Windows 2008/R2 athough I guess this may be different for editions such as Express.
For me, i'd be much more interested in knowing whether Denali tools were able to be installed on XP as this is often where I manage by SQL Servers.
Showing posts with label Version. Show all posts
Showing posts with label Version. Show all posts
Thursday, 23 June 2011
Thursday, 9 June 2011
T-SQL: Version your database with Extended Properties
Recently i've had a requirement to version a database build in a simliar way to AdventureWorks which uses a version table called AWBuildVersion. Of course, that is a perfectly acceptable option but as with all things SQL, there is more than one way to skin a cat. Extended properties are not a new feature to SQL Server but they might as well be for the number of times i've used them but the thought came to me that they could well be suitable for keeping version properties of a database.
Here is the code to generate the same database version info that is kept in the AdventureWorks build table.
This returns:

Will I use this going forward? The thing with extended properties is that they aren't a widely used feature and having the data in a table makes it much more accessible. As a result, its much easier to remember the syntax to update a database table than an extended property. Also, a database table is more "visible" so is less likely to be forgotten when you come to update the version.
Here is the code to generate the same database version info that is kept in the AdventureWorks build table.
-- add a version to your database
EXECUTE sys.sp_addextendedproperty @name = N'SystemInformationID', @value = N'1';
EXECUTE sys.sp_addextendedproperty @name = N'Database Version', @value = N'10.00.80404.00';
EXECUTE sys.sp_addextendedproperty @name = N'VersionDate', @value = N'2008-04-04';
EXECUTE sys.sp_addextendedproperty @name = N'ModifiedDate', @value = N'2008-04-04';
-- read out the version
SELECT *
FROM fn_listextendedproperty (NULL, NULL, NULL, NULL, NULL, NULL, NULL);This returns:
Will I use this going forward? The thing with extended properties is that they aren't a widely used feature and having the data in a table makes it much more accessible. As a result, its much easier to remember the syntax to update a database table than an extended property. Also, a database table is more "visible" so is less likely to be forgotten when you come to update the version.
Labels:
Documentation,
Extended properties,
SQL,
SQL 2005,
SQL 2008,
SQL Server,
T-SQL,
Version
Subscribe to:
Posts (Atom)