[cvsnt] Re: Managing SQL Server source with CVS?

Bo Berglund bo.berglund at telia.com
Thu Nov 13 21:07:29 GMT 2003

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

This seems to be digressing from CVSNT issues really, since it is
about a certain kind of source files kept in a CVS repository and
is not related to CVSNT as such.
But if noone objects I will waste a few more TCP packets on this and
then shut up....

Delphi or not?
Well, since our shop is a Delphi shop it is the natural choice of
programming tool for most any task. In this case we wanted an 
exe file that could be packaged with InnoSetup and used as a way
to deploy updates to our database.
For this we needed it to be able to connect to the server and execute
SQL scripts on the server while having a decent user interface where
progress could be displayed. We already had all of the base classes
to manage the database accesses in all kinds of modes so it was a
given thing to reuse that also for this task.
So basically we have packaged the main SQL engine of our "real" app
into the helper program.

What it does
As I spelled out before it is invoked by InnoSetup during execution of
a setup program with some parameters and indata files that have been
retrieved from the user and extracted by InnoSetup.
Then it uses these data to connect to the server and execute the

Alternate solution
It is entirely possible to execute the script files using existing
tools in a SQL Server environment, especially the OSQL command line
program. This was our first thought. But that will pop up a big ugly
black command window in the middle of our setup or if we start it
minimized the user will get no feedback at all. Both are not
acceptable, so we went the Delpi app way.

The real problem
All of the above is not focused on the real problem, just on the
deployment part...
The real problem is "how to manage the SQL sources so they will be
easy to maintain". Here we have our solution but there are many.
We started out at the beginning by scripting out the database contents
using Enterprise Manager to sql files. Then we examined these and
modified stupid names for indexes and such among others. We also
rearranged the data into files containing separate tasks for creating
the database structure, the procedures and the data. We also put in
commented out commands:
--WITH ENCRYPTION into all procedure declarations. These are replaced
by our helper with the real thing so all procedures created this way
are encrypted on the target.
Finally we rearranged all code such that it would be possible to
easily follow what is done (we drop a procedure if existing just
before we recreate it for example).
This was checked in as the first revision (after verifying that the
scripts created the database we wanted of course).

>From now on the developers are working exclusively through these
script files when they modify the database structure and we have rules
as to where the modifications should go and what kind of comments
should be added into the source. When they are satisfied they commit
their changes to a devel-XX branch on CVS.
When we are ready for a release we examine the branch and merge it to
TRUNK, then we execute our automatic build system (which exports files
from CVS and invokes InnoSetup compiler to make the setup file).

The helper functions can easily be recreated even using OSQL, you need
only start OSQL with the sql file as argument and some command
switches to make it operate. We had some extended needs, hence the
helper app.

I hope this was not too long for the newsserver, if so it will appear
when Tony has had time to review the message and release it...

(Bo Berglund, developer in Sweden)

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook