Skip to main content


 

Symptoms


Eugene's expressed a concern regarding the reason why we need to give the installer account dbcreator permissions in SQL when performing a re-configure. He also mentioned that when running a repair, the install account does NOT appear to need "dbcreator" permissions.
 

Diagnoses


As things stand at the moment, it appears as if the installer does NOT check for dbcreator permissions "on the fly". This is the reason that we have to close and restart the installer when (as an example) the install user does not have dbcreator or securityadmin permissions. You can grant rights in SQL, but it is not until you restart setup manager that we will pick this up.

If we can maybe perfrom this check "on the fly", we might not need this. If the user re-configured blackpearl and keeps the existing DB, we don't need it. If the user wants to create a new DB, he can click the change link on the "Database Configurations" panel, supply a new DB name and in this case, we WILL need dbcreator permissions and we can warn the user.
 

Resolution

In 4.7, Legacy databases will no longer be supported. The installer database model has been re-written and will no longer use the scripting method we use today to create, edit and configure databases. This in turns means that permission checks and executions methods have been re-thought and implemented for this new model.

The new model will be based on the SQL DACPAC Deployment, where we let SQL control a lot of the changes. The current behavior will be over-hauled with 4.7 and hopefully along with that, certain dependencies we have with regards to the dbcreator permissions.




 
Be the first to reply!

Reply