Updating the installer to handle user names irrespective of case revealed problems with the DB scripts.
Basic Problem
The problem was that during installation, the specified user name was mapped to lowercase by Postgres, but treated as case-sensitive by the install script. The solution was to treat it as case-insensitive throughout, which just meant that we had to map it to lowercase in the install script. Both Postgres and SQL Server are fine after that.
Revealed Problems
Trigger Scripts
Testing with Postgres was fine, but when I got to testing an SQL Server install, I found there were problems in the SQL scripts.
The root cause of those is kind of tied to the whole way we manage database scripts. In short, the new columns that were added to various tables for multiple covariates had also been added to various triggers. But the columns are only added to the table and view in the alter_12 script, while the script for initially creating the triggers had been updated to refer to those same columns. That meant that the trigger creation failed because the columns didn't exist yet.
The most practical solution -- though not a very satisfactory one -- was to duplicate the trigger-creation script, keeping the initial one as it was before multiple covariates, and running the new one from alter_12.
Other Problems
There was a use sahsuland instruction that was being invoked before the sahsuland database was created, and a trigger being dropped with no check for it existing in the first place. Those were straightforward to fix.
Updating the installer to handle user names irrespective of case revealed problems with the DB scripts.
Basic Problem
The problem was that during installation, the specified user name was mapped to lowercase by Postgres, but treated as case-sensitive by the install script. The solution was to treat it as case-insensitive throughout, which just meant that we had to map it to lowercase in the install script. Both Postgres and SQL Server are fine after that.
Revealed Problems
Trigger Scripts
Testing with Postgres was fine, but when I got to testing an SQL Server install, I found there were problems in the SQL scripts.
The root cause of those is kind of tied to the whole way we manage database scripts. In short, the new columns that were added to various tables for multiple covariates had also been added to various triggers. But the columns are only added to the table and view in the
alter_12script, while the script for initially creating the triggers had been updated to refer to those same columns. That meant that the trigger creation failed because the columns didn't exist yet.The most practical solution -- though not a very satisfactory one -- was to duplicate the trigger-creation script, keeping the initial one as it was before multiple covariates, and running the new one from
alter_12.Other Problems
There was a
use sahsulandinstruction that was being invoked before thesahsulanddatabase was created, and a trigger being dropped with no check for it existing in the first place. Those were straightforward to fix.