-
I might be pushing my luck lately, but in recent days I've had more than a few excellent solutions to my various queries so I have no doubt that someone will have some ideas on this one.
I have an application which is going to be release shortly. Up till now I've been using the VS package and deployment wizard which is very good. I am thinking however about subsequent releases and of course the ever present bug fixes.
I would like to use something to create a self installing update. Most likely, the update will simply overwrite the exe, but in some cases there may be a dll or ocx that is to be updated as well. All this can still be achieved with the files created by the wizard, but now comes the tricky part (for me anyhow) and that is the database updates.
I use an Access database since the ADO makes life easy for me, and since Access provides a good "poor man's" SQL DB. Occassionally, I might have to add a stored procedure or view (oops I mean macro or query) or even update the structure of a table!. I can do all of this through code but I would prefer it if the code was not part of my application. I would like the "updater" package to do the updates for me.
There are other ways of doing this too as I'm sure you'll see. My preference is for very little user fiddling if at all possible.
So, to the questions:
Are there good alternatives to the package and deployment wizard?
Are there any updater package wizards around?
How do other programmers go about deploying DB updates to a large number of installs? (Note that all my previous experience is on large scale database applications usually involviing Oracle and usually requiring my trusty DBA to do the work. Also, this is the first time I'm doing an app in VB as opposed to Java or LISP (hehe)
Any answers or suggestions are welcome.
Regards
Paul Lewis
-
You are right... there are several ways of doing this :)
Firstly I hate the deployment wizard.... while it might be good for straight "BLOCK" installations it has no flexibility or extra features like registry settings, choices of which modules, Custom/Typical, Check for existing software requirements (ie don't install if no MDAC 2.1 is installed etc).
For this I use InstallShield or Wise InstallBuilder. They come with what you might call a mini programming language that allows you to do these things.
But beside that... here is a possible solution for you.
As part of your standard application write a DLL that is for your updates. In it you place STANDARD functions that determine the version of your application, a function for converting the database to its new format and anything else you consider important.
Whenever your application runs and finds that the executable date has changed to that which is stored in the registry it calls the "Updater" DLL and asks it to do its job. The updater then modifies whatever it needs, sets the date of the exe in the registry and finishes it all off.
When you release a new version and the user installs it you write the "NEW" code into the DLL so that it can update to the latest structure. This is then distributed and always contains the ability to convert between a given version of your software and the next one. It also makes backups of the database and the executable files so that it can "roll" out should the user decide they didn't like the change or something went wrong.
It is all automatic and only happens the first time you run the EXE and its date doesn't match.
-
I don't know why you want to stop using the P&D Wizard if you've had good luck with it. Our company did however require me to stop using it and switch to InstallShield for consistency sake because that's what other groups in the company used. I wasn't anxious to switch, but I've found that InstallShield is pretty good and is more flexible then VB's installer. Another advantage it has is that many commercial programs use it so the installation look and feel of an app that uses it will be familiar to the user. In any case when I was using VB's installer I developed a program called DBMaint which is designed to do database updates based on commands stored in a database. The commands do things like add fields to a table, add tables, add indexes, add and delete stored procedures, etc. The commands are stored by release number so that a normal user can be updated for example from release 4 to release 5, but at the same time some other user can be updated from say release 2 directly to release 5 without any problems. I modified the setup1 program that comes with the Wizard to shell DBMaint when it was done. We now use DBMaint with InstallShield in much the same way. E-mail me if you want to discuss it further.
[Edited by MartinLiss on 06-28-2000 at 12:40 AM]
