Hi,

My team is developing a new version of a server software that must support several clients via a web service interface. This software was written in C# and published on IIS. It also uses a Microsoft SQL Server database.

The problem is that our client has requested that we maintain two or more versions of the software running at the same time, so we have created separate URLs that run each of the different versions, for example the following URLs contain the versions 1.0.0, 1.5.0 and 2.0.0 of the software: "http://server/software_V100/service, http://server/software_V150/service, http://server/software_V200/service".

Unfortunately all of those versions share the same database, therefore some of the stored procedures we created for the 1.0.0 version were changed in the versions 1.5.0 and 2.0.0, so we decided to add the current version to the procedures' names just like the URLs, for example the DoSomething.sql procedure in version 1.0.0 became the DoSomething_V150.sql procedure in the version 1.5.0.

Because of this we are expecting that our software will become an incredible mess before long, therefore we decided to look into a version control software that would tell us what stored procedures belong to which version of the software, which ones were added, which ones were modified, etc.

Currently we are using the Microsoft Visual Source Safe to store the source code, however we were looking for a program that would give us a chart of which procedure belongs to which version of the software.

Could someone please recommend me a program that does that?

Thanks,
Komyg

Recommended Answers

All 4 Replies

I am unaware of any version control software that keeps track of database items. Being as stored procedures are compiled, I would say it's nearly impossible. You could however, keep track of your scripts to create stored procedures in each of your apps and list them as being part of the source code.

Hi, thanks for your reply.

You are right, it is impossible to keep track of the compiled stored procedures, however on my post I was referring to the scripts that contain the stored procedures and not to the procedures themselves.

Do you know of a software that would allow me to say which script belongs to which version? I know I can do this in Excel or on Source Safe, however I was wondering if there is another way to do this, because I don't have full access to my company's Source Safe (I have to fill so many forms to access it that it is easier to do without it) and keeping track of all the procedures (there are more than 100) on Excel is kind of confusing and time consuming.

Thanks again,
Komyg

If you're really in need of this, it might benefit you to get on your companies VSS, and use it. I can't really think of anything that will help you other than another VC software set, but there aren't any specific to SQL script files that I know of, they're all general code project trackers.

Actually, my company does use Visual Source Safe as the default storage and version control software, however even though we need to fill tousands of forms to use it, that doesn't mean that we don't.

What I am looking for is a software that would just associate a script with a release version of our product and not a software that would store the scripts in a repository to keep track of every change made to them.

Since we need to maintain different versions of our product running, we need to keep track of which script belongs to which version. Whenever we upgrade the product some scripts are also updated, therefore the scripts belonging to the previous version become obsolete, however we are still required to maintain them.

In other words, we have ended up with several different versions of the same stored procedure in the same database and each of those versions is compatible with one or more versions of the product, what we need is to keep track of which scripts does each version of the product uses.

For example if there is a problem with the version 1.2.1 of our product, I need to know which scripts it uses so that I can only alter the scripts that really belong to this version. Also if for example the version 1.3.2 uses one or more of the scripts that I altered to correct the problem in the version 1.2.1, then I will need to test both versions before releasing anything to our client.

Thanks,
Komyg

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.