Server Principal is not able to access the database under the current security context error

Hi Everyone,

We’ve been seeing this error floating around and I figured it would be a great subject to blog about.

“[Microsoft][SQL Server Native Client 11.0][SQL Server]The server principal ‘USERID’ is not able to access the database “COMPANYID” under the current security context.”

This can occur when approving workflows, upgrading databases, or simply logging into GP.

Sometimes this can be resolved by running the Grant script against the company and system databases to ensure that the userID is added to the DYNGRP.

The issue could also be that the DBNAME columns in the SY00100 table wasn’t updated when moving company databases to point to a new System Database name.

If this is the case, then you can try running the following script against the company database to verify which DBNAME it is set to. We should see DYNAMICS, or whatever you named the system database that GP is using. If not, then we’ll need to update it.

SELECT * FROM SY00100

If the DBNAME doesn’t show ‘DYNAMICS’, then go ahead and run the following script against the company database to update it.

UPDATE SY00100 SET DBNAME = 'DYNAMICS'

Other times this is caused by a custom trigger either on one of the tables or in the system itself. A Dexsql.log might show the trigger being activated, but usually a SQL Profiler Trace is needed to discover that the issue is being caused by a trigger and to determine where the trigger is located. If it’s a system trigger, then you can use the following steps to test the issue without it.

1. Within SQL Server Management Studio, expand Server Objects.
2. Expand Triggers.
3. If there are any triggers listed, right-click on them and select to disable.

If you see this issue occurring when attempting to approve workflows, then there could be an issue with the logical files for the company database where they are either pointing to the wrong location or named incorrectly. When this happens, we need to look at the COMPANYID.LDF file within SQL and make sure that it is using the correct company ID.

1. Within SQL Server Management Studio, right-click the company database and select Properties.
2. Select Files from the left navigation pane.
3. Review the Logical Name files and the location it’s pointing to.
   1. If they don’t look like GPS<COMPANYID>Log.ldf, then you will need to update the name here.

Afterwards, the workflow in question will need to be re-created and the following script ran against the company database.

exec wfDeployClrAssemblies

That’s about all the scenarios that we’ve seen on our end. If none of these steps help with the issue, then we on the GP support team are always happy to help in a support case.

Until the next blog, good luck and stay safe!