I have an opinion thats been forming over the last decade:
Database dependency injections in setup are evil.
Unfortunatly, I also don't know if they are avoidable since many people expect an application to just work after being installed.
Eitherway, what is the best of class solution? I've not seen one yet.
Back in the 90's I was responsible for putting together 500MB+ tarball packages for a massive Unix based server system. One of the modules in the package deployed a series of Informix databases either from scratch or upgrade from a previous release. Other parts of the system configured the operating system, nightly/weekly/monthly CRON jobs an many other tasks.
Does anyone want to guess which part of the install failed the most often?
Yup, you guessed it... the database updates. Think about it, with over 1300 stored procedures, each one of those sql files was basically an untrusted out of process script which could introduce fragility into the package. On top of that, the sql scripts to deploy and upgrade the databases had even more complexity with all sorts of dependencies that would make the install even more unstable.
The truth is we frequently extracted the package, manually turned off the database updates and then ran the install. After we'd call a DBA on duty and ask them to manually update the database.
Yes, that's a horrible release strategy. But that's what the release manager ordered to keep the schedule.
I recently read a post on in the InstallShield community forum where a user was asking why an install could connect to sql server using localhost but not (local). My thought was to test if other sql clients could connect as (local) and then check the sql configuration. The posters response was:
I don't want our customers to have use any special SQL Server configurations. This software should work out of the box.
Unfortunatly, my opinion is becoming that these statements are mutually exclusive when dealing with datalayer dependency injections. Unfortunatly most developers I come across seem to have this overly simplistic understanding of the challenges of database deployment and maintenance. They want to throw extremly how level requirements along the line of 'The install should just work.' and then throw extremly technical challenges with many possible configuration variations.
I'm sorry, but I just haven't seen it work that way yet.
So I'm very, very interested to know what my readers think on this subject. Have you had the same pain or have you found a better way to deal with the challenges? Also do you have the same problem that I have: People don't seem to understand that when an install breaks because of a sql dependency injection that it wasn't the installs fault. After all, it wasn't the setup engineer who made the decision to inject the custom action and it wasn't the setup engineer who was responsible for developing or testing it.