views:

99

answers:

6

Simple situation. I've created an application which uses SQL Server as database. I could add a table to this database which contains the version number of my application, so my application can check if it's talking to the correct version of the database. But since there are no other settings that I store inside a database, this would mean that I would add a single table with a single field, which contains only one record.

What a waste of a good resource...

Is there another wat that I can tell the SQL Server database about the product version that it's linked to?

I'm not interested in the version of SQL Server itself but of the database that it's using.

(Btw, this applies to both SQL Server 2000 and 2005.)

+1  A: 

I'd go with the massive overhead of a varchar(5) field with a tinyint PK. It makes the most sense if you're talking about a product that already uses the SQL Server database.

You're worried about overhead on such a small part of the system, that it becomes negligible.

Randolph Potter
Plus, you may find additional use for the configuration table for other parts of your system.
Randolph Potter
Actually, since this database will be used by other developers in the future, I'm worried that they will misuse it to store all kinds of options for the application, while I prefer to keep those settings on the client side.
Workshop Alex
Fair point. The Extended Property suggested by CodeByMoonlight is the most reasonable solution then. I didn't even think of it :-)
Randolph Potter
A: 

You're worried about wasting a table? I'd be more worried about putting the data in an unrelated table and confusing all of the developers who come after you.

tvanfosson
They should just read the technicak design first before messing with the code...
Workshop Alex
Using a table is the simple way to do it and worrying about a single table that contains a configuration item is too much optimization. Choosing to do something in an unexpected and, potentially, more complicated way is a way to introduce bugs, frustrate future developers, and end up on the Daily WTF, and not in a good way.
tvanfosson
Well, I disagree. I don't want another table that would confuse other developers. (Besides, it would allow developers an easy way to "alter" the version number, which I definitely don't want.) Basically, by keeping it a bit complex, I'm discouraging less experienced developers from messing with it.
Workshop Alex
I'd say that you have bigger problems than where to keep your product version if you feel that obscuring things from other team members is a good or necessary thing.
tvanfosson
A: 

I would put the connection settings in the application or a config file that the application reads. Have the app check the version number in the connection settings.

J.Hendrix
Not interested in connection strings...
Workshop Alex
It is sad that you felt the need to vote an answer down just b/c you are not "interested" in doing it one way. I was only trying to help and I feel that I gave a valid answer, just not the one you want.
J.Hendrix
I downvoted because your answer isn't in any way related to the question. I'm asking about a product version number and you're referring to a database connection string. It can't be an application-side version number. It needs to be tied to the database structure!
Workshop Alex
+1  A: 

Even if there was such a feature in SQL Server, I wouldn't use it. Why?

  • Adding a new table to store the information is negligible to both the size and speed of the application and database
  • A new table could store other configuration data related to the application, and you've already got a mechanism in place for it (and if your application is that large, you will have other configuration data)
  • Coupling the application to a specific database engine (especially this way) is very rarely a good thing
  • Not standard practice, and not obvious to someone new looking at the system for the first time
Jon Seigel
The project is not supposed to be handled by someone new and inexperienced. There's a large, technical document which explains how it's built and why certain decisions have been made. No one is allowed to change things before they've read and understood this document.
Workshop Alex
A: 

I highly recommend writing the data base version into the database. In an application we maintained over a decade or so we had updates of the database schema every release. When the user started the application after an update installation it could detect if the database was to old and convert it to the newer schema. We actually did an incremental update: In order to get from 7 to 10 we did 7 -> 8, 8->9, 9->10. Also imagine the scenario when somebody restores the database to an older state from a backup.

Don't even think about adding a single table, just do it (and think about the use cases).

ur
This is what I would do if there is no other solution. But I want to know alternatives so I can check if those alternatives will add some practical advantages.
Workshop Alex
+2  A: 

If you're using SQL 2005 and up, you can store version info as an Extended Property of the database itself and query the sys.extended_properties view to get the info, eg :

sys.sp_addextendedproperty @name=N'CurrentDBVersion', @value=N'1.4.2'

SELECT Value FROM sys.extended_properties WHERE name = 'CurrentDBVersion' AND class_desc = 'DATABASE'

If SQL 2000, I think your only option is your own table with one row. The overhead is almost non-existent.

CodeByMoonlight
That seems to be the trick I was looking for! Too bad it doesn't work for SQL Server 2000...
Workshop Alex
In SQL 2000 you can add extended properties to pretty much every object except the DB itself.
CodeByMoonlight