Cannot log into Microsoft Dynamics GP 10 (one user and any new user) due to ODBC DSN
After a day of troubleshooting why (1) user (plus any newly created users) could not log into GP, we finally have a workaround.
Unfortunately, we don't have a solution or explanation as to what's happening.
Received a call from 'UserA' that they could not log into GP this morning. Checked logs and saw this:
Login failed for user ‘UserA'. Reason: Failed to open the explicitly specified database.
Error: 18456, Severity: 14, State:38
Turning on SQL logging in the dex.ini file, we find that it's opening a company database, by default, of a company she does not nor should have access to.
We cannot figure out why it's opening up to database 'compabc' when it is supposed to default either to 'master' or 'DYNAMICS'.
We checked the ODBC connections, and nothing was explicitly set there. Furthermore, this happens from any computer in the domain for this username, or for any username we newly create (all other older users work fine).
We use Dynamics GP as the DSN on all workstations; we found that we could go to a workstation and change the DSN to DynamicsGP (no space) and 'UserA' could login to GP just fine and we confirmed she was accessing the default database of DYNAMICS,
What is going on here? Somehow the Dynamics GP DSN for the Native Client connector is tied to the wrong default database for this user and all new users, but none of the other older users (some of which also explicitly do not have access to 'compabc' database, but are just fine).
Any ideas on what's going on?
Unfortunately, we don't have a solution or explanation as to what's happening.
Received a call from 'UserA' that they could not log into GP this morning. Checked logs and saw this:
Login failed for user ‘UserA'. Reason: Failed to open the explicitly specified database.
Error: 18456, Severity: 14, State:38
Turning on SQL logging in the dex.ini file, we find that it's opening a company database, by default, of a company she does not nor should have access to.
We cannot figure out why it's opening up to database 'compabc' when it is supposed to default either to 'master' or 'DYNAMICS'.
We checked the ODBC connections, and nothing was explicitly set there. Furthermore, this happens from any computer in the domain for this username, or for any username we newly create (all other older users work fine).
We use Dynamics GP as the DSN on all workstations; we found that we could go to a workstation and change the DSN to DynamicsGP (no space) and 'UserA' could login to GP just fine and we confirmed she was accessing the default database of DYNAMICS,
What is going on here? Somehow the Dynamics GP DSN for the Native Client connector is tied to the wrong default database for this user and all new users, but none of the other older users (some of which also explicitly do not have access to 'compabc' database, but are just fine).
Any ideas on what's going on?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi,
In that case, I have had a nearly identical issue.
I spent hours trying to figure out why a new GP user could not login. After tons of searching and testing, I submitted a support case with Microsoft.
After trying a bunch of other things, as a hail mary, they had me try the old SQL Server driver on the DSN.
That resolved the issue.
When I asked why, and what I should do then, they said to just use the old driver. They had no explanation as to why it worked or why I should have to use the old driver. I was baffled.
Sounds very similar to what you are experiencing.
Thanks,
Steve Endow
Dynamics GP Certified Trainer
Dynamics GP Certified Professional
In that case, I have had a nearly identical issue.
I spent hours trying to figure out why a new GP user could not login. After tons of searching and testing, I submitted a support case with Microsoft.
After trying a bunch of other things, as a hail mary, they had me try the old SQL Server driver on the DSN.
That resolved the issue.
When I asked why, and what I should do then, they said to just use the old driver. They had no explanation as to why it worked or why I should have to use the old driver. I was baffled.
Sounds very similar to what you are experiencing.
Thanks,
Steve Endow
Dynamics GP Certified Trainer
Dynamics GP Certified Professional
ASKER
Sendow,
Ugh... not what I wanted to hear but thanks for sharing =)
By that measure, I'd need to install the old driver on each new PC and then go around and switch the drivers on other PC's... because there are times different users log into different PC's and access GP with their own credentials.
I'd hate to do that and screw up any of the existing logins that work... I suppose changing back the driver if it borks should theoretically work; just don't like theoretical in a situation like this.
Thanks again for the response.
Ugh... not what I wanted to hear but thanks for sharing =)
By that measure, I'd need to install the old driver on each new PC and then go around and switch the drivers on other PC's... because there are times different users log into different PC's and access GP with their own credentials.
I'd hate to do that and screw up any of the existing logins that work... I suppose changing back the driver if it borks should theoretically work; just don't like theoretical in a situation like this.
Thanks again for the response.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for your help, but we still have not resolved the situation. We were able to get around it by using a different DSN, which is fine for this scenario as the user only logs onto the domain and queries from specific workstation.
ASKER
Thanks for the response.
I was surprised too when changing the DSN allowed login... I thought with the way GP encrypts the password that changing the DSN would make the login fail.
(1) We use native client and the same DSN everywhere... what was more odd is that we attempted during testing to try the non-native SQL Server client and that worked as well.
(2) We have exhausted this and I am fairly certain that it's not user-specific, since it is happening now to any newly created user.