2
Within our test environment if I attempt to change a user password, I am using sa, I am getting a message 'unable to perform task, check the administrator'.
This is the same with all users, even if I try to create a new profile. Can I restore the 'dynamics' backup from production to the test to get out of this issue? I am thinking the credentials will be current? The test environment is approximately 8 months old.
*This post is locked for comments
This last error: "The password change failed for an unknown reason. Enter a different password or contact your system administrator", we've seen caused by using an ODBC System DSN not using SQL Native Client for the driver as per KB 913823.
KB 919345 is another support case I'd recommend looking over if you haven't already done so.
Also, make sure the ODBC System DSN being used is as per KB 870416, such as all ANSI options un-marked, the default database set to 'Master' and the SA login and password is being used.
Also, what does the dexsql.log show when you get this error message?
We may need a support case opened to look at this with you, as there are multiple causes for this type of error message and in cases like this, it's usually easier to get remoted onto the SQL environment and look at everything.
Thank you,
Thanks for your response, as you suggested earlier the message may relate to the system database not having all the tables, the restore was done over.
I am now able to log on to the test.
The attached is the message I am getting now, which was what I was getting previously. I was hoping the restore would have fixed that. We use the test for training, as well as testing pending changes, but as it is if I can't change any credentials of existing profiles .
I am able to create new profiles, I will have to work with that, thank you for your assistance.
As per KB 870416, you need to use a 32-bit ODBC System DSN with Dynamics GP. Normally if it is a 64-bit DSN, you won't even see the DSN's name in the 'Server' field of the Dynamics GP login window, to choose from.
In regards to this 'working before', there isn't any way for us to say what may've happened, we can just give you information based on the error message.
Otherwise, I'd recommend opening a support case for Dynamics GP, so that a technician can take a look at your system with you to see what may be setup incorrectly and thus causing these errors to show and not be able to change a user password.
Thank you,
Hello Rosemary,
As mentioned on here, if setting up a test environment of Dynamics GP, you'd want to move a copy of the company database(s) as well as the DYNAMICS/system database for GP over to the test environment, then go through KB 878449 to move the login information over to the new SQL Server as well, otherwise on the test environment, only SA would be able to login to Dynamics GP successfully.
Also, we frequently see that on the test system, you need to logon as SA into Dynamics GP and reset the user's password within the GP application to get the encryption to work and allow the users to login successfully as well. Unfortunately, there isn't any way to do this process in mass.
The errors you're getting make we wonder if you're not dong more or if you don't have something else in play as you're getting messages about the DB_Upgrade and 'Failed Upgrading Table'.
Looking at support cases we've had referring to this error and the 'Error message 35100 doesn't exist', we've seen this point to using a 64-bit ODBC instead of a 32-bit which is required for use with any version of Dynamics GP, as per KB 870416.
We've also seen this caused by the DYNAMICS system database not having all the tables in it, that it should, and various causes like that.
I'd say make sure you're using a 32-bit ODBC, and then if so, run the following scripts and return the results:
1. Select INTERID, * from DYNAMICS..SY01500
2. Select * from DYNAMICS..DB_Upgrade where PRODID = 0
3. Select * from DYNAMICS..DU000020 order by companyID
Thanks,
Yes Rosemary, you need to take both Dynamics DB and the company DB. As you are moving to a new server, you will have to consider the capture login sql script, you shall run this on your production server.
The instructions are provided under Article ID: 878449
The article illustrates how to migrate a Dynamics GP to a new server, consider the initial instructions provided accordingly.
Try refreshing both Dynamics and Company DB. and then download the script from the below link to copy logins from prod to test. Also make sure db owner is DYNSA on both the databases.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,214
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (