Unhandled Object Exception Access is Denied Party!

So today I encountered a rather odd situation.  The client was able to access GP, but when clicking on a home page or area page she would receive "Unhandled Object Exception" and "Access Denied" errors.   Other than "Access Denied", the "Unhandled Object Exceptions" would also say "Error Calling Method Save".  So it seemed to be a permission issue obviously :)

I found some references to errors with the home page being tracked back to the appropriate files not being found in the Backgrounds folder:
AreaPage.xsl

HomePage.css
HomePage.xsl
PreviewPane.xsl
So we checked it out, and the files were all in the appropriate location.  Dead end. 

But we did find that the user could not create a file in the C:\Program Files\Microsoft Dynamics\GP\Backgrounds folder.  But changing the permissions on that folder did not correct it.  So we check the plain ol' C:\Program Files\Microsoft Dynamics\GP folder.  Oddly, it had been set to Read Only as well.  So we changed both, and viola! the user can log in and access home pages and area pages successfully.

But this begs the question(s)....
1.  What are the true minimum permissions for the Microsoft Dynamics GP user directory?  A poll of coworkers said "Full Control" and I know that is what I have always done.  But is that true?  Could we get by with less (and appease many IT folks who would cringe at the "Full Control" notion)?
2.  Also, what would have changed the permissions for all users?  A gremlin?  A gnome?  Something had to change it, right?

So this post ends with more questions than answers, but I found it all interesting regardless so I thought I would share!

Invalid object name 'DYNAMICS..taErrorCode'

Full moon? Sun spots?

Tonight I was installing a new eConnect integration on a client's development server.

When I ran the integration, I received the following SQL Exception error:

Invalid object name 'DYNAMICS..taErrorCode'

I've developed and deployed countless eConnect integrations, and have never seen this before. A search for this message via Google and PartnerSource produced no meaningful results.

When I checked the Dynamics database, sure enough, there was no taErrorCode table. eConnect 10 was installed and configured on the server, and the Release Info tool even reported that it was installed on all databases, but for some reason the taErrorCode table did not exist.

I didn't install GP on the server, and I can't explain how or why the table would be missing, or what else may be missing. I also don't know of a "proper" way to recreate and populate the table.

I ended up scripting the table on my development server and manually recreating it on the client's server.

For the over 7,000 records in the table, I then tried to use the SQL Import Export Wizard to export the data from my machine to a file that I could then import on the client's machine. But after numerous cryptic errors that prevented the file from importing, I had to give up on that option.

I eventually created a new database on my server, copied the table and its contents to that empty database, backed up the database, restored it on the client's server, and then used the Import Wizard to transfer the data from that database to DYNAMICS.

That seemed to resolve the issue, and now the integration seems to work.

Bizarre.

Forecaster Database Creation Wizard Failure :(

Creating a new database in Forecaster is generally a straightforward affair. Launch the Forecaster Database Creation Wizard, connect to the desired SQL Server, enter the information for the new database, and there you have it. Or, sometimes, you don't. Last week I ran in to an issue where the wizard would "quit unexpectedly" after I had specified the new database name and clicked Next. Odd. I tried it from another machine, same result. But, then, I tried creating the database on a different SQL Server and it worked. Hmmm. I checked the Application Event Log, and sure enough there was a .Net Framework error (not very descriptive, but an error nonetheless).

Turns out, the issue was the original SQL Server we were using had offline databases. I would have never thought to check that, the tech assigned to my case mentioned that they had seen similar issues caused by offline databases on the SQL Server. So we removed the offline databases, and the wizard runs without issue.

Just thought I would share this with you all, as it's not something that I would have thought of on my own :) Happy forecasting...

"Unable to load SanScript Library" and Integration Manager

Late last month, I was asked to assist a client who was having issues with the year end update for Dynamics GP. After I had helped her through the issue, she mentioned that she had an issue with Integration Manager that her previous consultant could not resolve. She had even gone so far as to completely wipe and reload the machine in an attempt to address the issue. Naturally, in the middle of a million year end questions, this issue actually sparked my curiousity :)

She showed me that on one machine, if she tried to run an integration, it would appear to start and then would display the error "Unable to load SanScript Library". Like any good consultant, I immediately checked the KnowledgeBase and found a few articles that discussed the following possible causes and resolutions...
1. Corrupt install or corrupt IM.dic: Uninstall, clean registry, and then reinstall
2. Corrupt integration: Recreate integration

I knew she had been through #1 several times, so I tried #2 and still received the error. I tried using a backup IM.MDB, and still received the error. Hmmm.

So I started to think about the corrupt IM.dic mentioned in the article. And I started to think about how many of the articles mentioned the error when opening an integration, but she did not the error until she actually ran the integration (and that it appeared to run at first before displaying the error). It was as if it was having issues with pushing the data through the Dynamics GP client, as opposed to an issue with the Integration Manager application itself. And then I remembered that she launched Integration Manager from the start menu, because the option from Tools>>Integrate was not available to her.

I bet many of you already know where I am heading with this. I checked her Dynamics.set file (her launch file, through Tools>>Setup>>System>>Edit Launch File) and, sure enough, Integration Manager was not included in the launch file. The IM.dic was were it should be, in the GP directory, but the Dynamics.set was not even looking for it. We modified the launch file to include Integration Manager (by copying from the Dynamics.set on a working workstation), and the integration now runs perfectly.

This was on GP 9, not sure if others have run in to it on GP 10. But I thought it was an interesting find that I should share with others, to spare you the troubleshooting should you come across it. Happy New Year!