How to handle database dependencies in a dll?

Question

5.00/5 (1 vote)

See more:

, +

Hi all,
I have a question about how to handle database dependencies in 'generic' dll's.

For example, I have written a dll that logs exception information to a database. We want to use this functionality for multiple customers.
Now let's assume I have used this functionality for customer A and a colleague has used it for customer B. The first setup is easy. Run a database script and use the dll in your code. The dll will then write to the database.

Now for customer A I make some changes to the database schema, let's say I log some extra information. Now when my colleague goes to work for customer B (perhaps a few months after I made the changes!) his software will crash because the new columns are not in his database. In a worst case scenario he forgets to update the database of customer B and the code will crash in production (shame on my colleague, but he may not be aware of any database changes at all).

What is a good way to handle this?
Should I have a database script for version 1 of the dll, version 2 of the dll (that also includes version 1 if it is not yet installed) etc.
Should I check if a table and record specifying the use and version of the dll in the database and show an error when it is not present?
Is there some kind of tool that can easily keep seperate versions of the dll with the corresponding database scripts?

Does anyone have a good solution for this that doesn't require every user of the dll to be aware of database scripts and changes?
Perhaps built-in solutions, programmable solutions or third-party solutions?

The database(s) I'm using are SQL Server 2005 and higher and the software is .NET4 (both VB and C#) in Visual Studio 2010 (we might switch to a newer version soon).

Thanks.

Posted 15-Jan-14 0:23am

Sander Rossel

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Pete O'Hanlon · Accepted Answer · 2014-01-15T00:49:00

Solution 1

What you are talking about is software versioning, and it's part of a very big topic - release management. Whole books can be written about this area.

So, the big question is, are there any simplistic ways of achieving this? The answer is yes, but it requires you to put quite a bit of infrastructure in place in your DLL right from the start. The first thing you need is a way of recording what version your DLL is currently at in the database. A simple table will usually suffice here consisting of a string containing the version. When your DLL is invoked, the first thing any method in it has to do is check to see what the version is in the database. If that version is less than the current version, then you need to apply your scripts to update the database in the correct order.

Fortunately, actually writing this infrastructure isn't that complicated.

Posted 15-Jan-14 0:49am

Pete O'Hanlon

Comments

Sander Rossel 15-Jan-14 7:12am

Thanks for your answer.
That sounds reasonable. So in a call to my dll I do the following:
1. Check if our software version table is present in the database.
2. If it isn't create it.
3. Check if the record for the current dll + version is in the table.
4. If it isn't create the record with the correct version and put all database infrastructure for the dll in place.
5. If it is present, but the version is out of date update the record and update the current database infrastructure for the dll.
6. If it is present and up to date, do nothing.
Those steps should ideally be handled by a seperate dll that can perform those steps for every dll that needs a specific database infrastructure.

Speaking of release management, do you know any good books I should read?
So far our company has been manually copying dll's to our customers computer and so far this was never a problem.
More recently our company started to embrace more object oriented principles and we now split common functionality in dll's for re-use.
Unfortunately our release 'strategy' is not always suffient anymore and we need a more structured and automated approach.
If you know of some good book(s) I'll certainly look into it in more detail.
There are more aspects that could certainly use improvement (even though they aren't a problem yet).

Pete O'Hanlon 15-Jan-14 8:40am

Depending on how much buy in you can get from management, you could go with this book: http://www.amazon.co.uk/Implementing-Release-Management-Infrastructure-Library/dp/0138150419. The big thing with release management is that it requires buy-in from all levels. It's worth pushing to get it done though. Managing it is a full time job which is why I have a release manager.

Sander Rossel 15-Jan-14 9:51am

Thank you Pete. I'll discuss this with my managers and see if this will help me and the company.