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 scripts. 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 (Bo Berglund, developer in Sweden)