You’re offline. This is a read only version of the page.
285
I am using SL 7.0 Sp3 w/ AD authentication. The issue is with how solomon's security model is setup. When doing a PV Lookup I get "The server principal "dom\dummy.user" is not able to access the database "OthernonSLDB" under the current security context. I did all the groundwork and granted the "dom\dummy.user" login read access to "OthernonSLDB", I even tested it outside solomon by running the sql text from the PVREC record in SSMS under the dummy.user account. I ran successfully.
As another tidbit this function was working in version 6.5. All I needed to do was grant Master60sp to the other Database.
Has anyone done this in V7 with AD authentication?
*This post is locked for comments
I have the same question (0)
Albert,
Dynamics SL uses a feature in SQL Server called “Application Roles” to grant an Active Directory (AD) User access to the Dynamics SL tables. When using the Integrated Security model in Dynamics SL this poses a problem with queries that cross databases, as application roles are database specific (meaning the security does not cross databases).
If your code is calling a stored procedure, you can get around this issue by using an “EXECUTE AS” clause in your stored procedure, but this is not something the Possible Values (PV) functionality in Dynamics SL currently supports. I can think of two options for you. The first is to not use Integrated security and use SQL Security, but this seems to be going against the long term direction of the product and may not be a realistic option for your organization.
The second option would be to create a read-only copy of your source table (perhaps with only the columns you need in the PV window) in the actual Dynamics SL database. You would need to define a method for keeping your copy table up to date, but this is something we have used to work around the issue you describe.”
Share
Report
All responses (
Answers (
