- UNIFYBroker Forum
-
Bugs
v5.3 Installer fails when SQL filenames do not match the DB name
Attempted an upgrade of Identity Broker from v5.2 to v5.3, the upgrade process failed running the following SQL Commands
ALTER DATABASE [Unify.IdentityBroker_DEVAP610] SET RECOVERY SIMPLE;
ALTER DATABASE [Unify.IdentityBroker_DEVAP610] MODIFY FILE (NAME=[Unify.IdentityBroker_DEVAP610], FILEGROWTH=100MB);
ALTER DATABASE [Unify.IdentityBroker_DEVAP610] MODIFY FILE (NAME=[Unify.IdentityBroker_DEVAP610_log], FILEGROWTH=100MB);
The installer did not revert to the previous version of Identity Broker, instead it removed the service from the Services window.
I located the commands above in the Windows application log and attempted to run the command in SQL directly, it did not work as the files were named differently than names in the SQL Configuration.
In this case I renamed the SQL files as it is non-production and was able to run the installer successfully. I recall this issue with v5.2 and run through the DB manual upgrade process. I think this needs to be fixed for users that are not as familiar with installation options.
I am also not sure the settings should be made in the installer, if the SQL instance is clustered it will not support simple logging, also in large implementations I normally make the database file group by 1GB.
Customer support service by UserEcho
The install/upgrade options are really to cover the 80% (probably more) that next>next>next their way through and don't change anything, with the manual option being there for the other cases. We were seeing a large number of issues caused by this behavior, so wanted to get the best "generic" settings done on install.
I could probably get the script to discover the current file names so that it gets that right, would that help? Do you have a suggestion on how to deal with the 20% without compromising too much on the 80%?
I would suggest not running this particular command during if upgrade DB is selected, only on new install.
I have not done a lot with SQL Clustering but I believe it is created, then clustered so Simple logging during install would be fine, it can be changed later manually when clustering.
That should be possible. I'll add it to the backlog. Thank you for the suggestion.
I've only seen this when the service was still running (the process). Do you happen to recall if this was the case? Other than that I don't have much control over the behavior, it's using the Windows service installer in combination with a major upgrade - both of which are standard controls.