Recently, I faced an issue where a user was unable to add an employee to a newly created test company. After marking the “Test Company” checkbox under the User Access Setup window (Tools | Setup | System | User Access) and clicking “OK,” four separate error messages popped up.
From prior experience, I was fairly certain the first error related to user security access on the database level being different from what Dynamics GP was showing. Usually, it results from someone adding or removing user permissions in the SQL database.
I did not know what the second error related to at first glance, and rather than search for an answer, I decided to see if any of the other errors were more descriptive.
When I got to the third error, I had some information I could work with: the error related to a stored procedure, MXCallRevokeUserAudit, not being found. As I was unfamiliar with the stored procedure, I investigated further. I soon realized all tables in the “Audit Trails” module started with MX, so now I knew the issue was somewhere in the “Audit Trails” module. This information quickly led me to a post by Vaidyanathan Mohan detailing his experience with the same issue, which can be found on Vaidymohan.com.
While Vaidyanathan’s error resulted from attempting to revoke a user’s access, the principle is similar. In his post, he details that he was able to eliminate the error by removing the “Audit Trails” module, but what if the end user doesn’t want to disable the module? After speaking with the client, I confirmed they did not want to remove the module, so we would need to come up with a different solution.
I waited until after business hours, ensured all users were logged off and pulled up the Dynamics.SET file. I first made a copy of the file—always make a copy!—and then modified the file by deleting the following: 4966 Audit Trails, 4966MS.DIC, FRMS4966.DIC and RPTS4966.DIC. I then modified the first line of the Dynamics.SET file to one less than the number listed to reflect the removal of a module. We then logged into Dynamics GP and attempted to add access to the test company for the affected user. Instead of four errors, we received only one this time.
I spoke with the system administrator and determined that access was granted in SQL Server Management Studio in an attempt to correct the original three errors internally before contacting our team.
We logged out of Dynamics GP and removed the user’s access to the test company database within SQL Server Management Studio. Upon logging back into Dynamics GP, we were able to successfully add access to the test company for the user. As a final step, we logged out of Dynamics GP, replaced the modified Dynamics.SET file with the original file and verified the user could log in and access the test company.
While disabling the “Audit Trails” module does resolve the error message, you can use the temporary disabling method I used to circumvent the issue without disabling the module during normal day-to-day activity. If this error becomes persistent, a more detailed analysis will be needed, but in a time-sensitive environment, the best path often is the path of least resistance.
If you are a BKD client and would like further information regarding this post, contact our Microsoft Dynamics GP support center at GPsupport@bkd.com.