Synchronization Error when running Report for certain users

deV.ch

I'am facing a strange error since moving an existing well working environment from one sql server to another. Certain users, not all, receiving the Error:

"The Microsoft Dynamics NAV Classic and SQL Server security systems have not been successfully synchronized.  The SQL Server login <User> does not exist on the <Server> server."

It happens when a user wants to preview a report. Or when calling a webservice, but again only for certain users!

Security Model ist standard. We already tried to synchronize, that works well with no error, but doesn't solve the problem!

UPDATE:
We traced down the problem to code that modifies an entry in the Navision User Table (T2000000002). This code is used for report selection and is proven to work before the shift of the database to the new server.

We also noticed that users with sysadmin permission do not have the error message, so i guess it's a sql server permission problem.

Does anybody know what kind of rights we need to set on sql side to get it working?

kine

Try to compare permissions for the Application role on the SQL on th enew DB and on the previou or another working one. It seems that it is missing some permissions.

deV.ch

Since we haven't found any difference and comparing permissions is hard to achieve, we did a workaround, which indeed isn't realy a workaround but more like the right way of doing this:

Since you don't have permission to synchronize in NAV unless you have the db_securityadmin role the behaviour we faced was as expected. Someone must have changed permission settings in a way to allow all users to synchronize, that is not what we wanted, and what should be done.

So the real problem behind all this was that, when you have a field on the User table, and you are using Standard security model, then as soon as you modify a record in that table, the system well do a sync, but since that code will be executed by users without the db_securityadmin role, this will fail, and must fail.

So the "workaround" (or the right way of doing this on the first side) was to move the fields to the "User Setup" Table.