I recently received an inquiry about a GP 10 installation that suddenly stopped working. While posting a batch, GP had crashed, and would not launch again.
When the user tried to launch GP, they would receive a message saying that GP Utilities need to be run first: "You need to run Microsoft Dynamics GP Utilities before you can run Microsoft Dynamics GP."
But when GP Utilities launched, it then said that the Dynamics system database did not exist, and it had to be setup. "The Microsoft Dynamics GP system database has not been created for this installation."
It was as if GP had just disappeared from the machine and SQL Server.
Puzzled over this, I then checked the SQL Server to confirm that the databases did in fact exist. The database files were present, SQL Server Management Studio displayed them, and I could query them without issue.
Hmmm. So everything looked okay to me, but clearly GP didn't agree.
So I then decided to run SQL Profiler while launching GP Utilities to see what Utilities was doing that caused it to think that the Dynamics database didn't exist.
What I found explained part of the issue, but was puzzling--Utilities was looking for a blank database name, which is why it couldn't find the Dynamics database.
I then tested Utilities on another machine to confirm what the query should look like.
Sure enough, Utilities was not only issuing completely different SQL statements when launched, but it was also not properly querying the Dynamics database.
To continue this process, I walked through the initial steps of the Utilities setup process to see if there were any more clues. And when I got to the System Database setup window, I received another clue.
The database file names were missing the usual "DYNAMICS" name.
So, here's the million dollar question:
What could suddenly give both GP and GP Utilities complete amnesia, to the point where neither even knew the name of the Dynamics database?
Well, the problem was clearly happening before any SQL queries were issued, and clearly the SQL Server and databases seemed okay, so I figured that the problem must be with the Dynamics GP client.
After pondering for a few seconds, I took a look at the Dex.ini. And sure enough, there was something curious going on. This is all that I saw:
When I pulled up a Dex.ini on another GP server that worked, this is what it looked like:
So, somehow, when GP had crashed during posting, it had mysteriously wiped out the majority of the contents of the Dex.ini file.
This in turn gave GP and GP Utilities complete memory loss, and caused the unusual symptoms.
I was able to copy the contents from the working dex.ini file and make a few tweaks, and GP worked fine again.
Another bizarre problem solved, and yet another example of why you should have a good BACKUP PROCEDURE for your Dynamics GP environment.
Hi Steve
ReplyDeleteTo me this sounds like Dexterity is unable to find or gain read/write access to the dex.ini file.
In this case it will create a new one in the user's home folder.
What OS and version/build is this for?
David
http://blogs.msdn.com/DevelopingForDynamicsGP/
Hi David,
ReplyDeleteIt is GP 10 SP3 installed on Windows Vista (with UAC disabled). It is only a test machine that a developer and I use for testing and prototyping, so I can't rule out that the environment has some quirks.
I just did a test, deleting the dex.ini while GP is open, and then closing GP, and although the dex.ini is not exactly the same as what I saw, it does have some entries, so I think your theory makes sense.
So perhaps somehow the dex.ini got wiped or deleted, and GP recreated a new dex.ini and populated it with the handful of values that it could.
Steve