GP 9 Windows Won't Open or Error After Importing Package Files

Here's a fun Wednesday morning GP brain teaser.

I have a copy of a client's GP 9 Dynamics and Company databases setup in a development environment. I have developed several Modifier & VBA mods for this client, so I open GP to make some changes to one of the mods.

GP appears to work properly, but when I try and open the Sales Transaction Entry window, where I have some VBA code, nothing happens. No error, no window, nothing. When I try and open the Customer Address Maintenance window, where I have both Modifier and VBA changes, I get an "Unhandled script exception EXCEPTION_CLASS_FORM_MISSING" error.

Very odd. Nothing in the Knowledge Base seemed to specifically address this issue, although there were some references to security being the culprit.

I then check Advanced Security and try switching back to the standard GP windows. No dice, still have the problems.

So then I delete the Dynamics.vba file and Forms.dic to remove my customizations. GP then worked fine, windows would open, no errors.

As soon as I import just one of my packages again, the problems return.

My intuition is telling me that it isn't the mods themselves, as they are quite basic, and should never prevent windows from opening. So my thought is that the problem is somehow related to security. I just can't tell what the problem might be.

So I try to open the SOP Transaction Entry window again. Nothing. I then launch SQL Profiler to see if any queries are being performed as I open the window.

When I run the trace, I see that there are 6 queries. One is a select against Dynamics SY02000, which is the Security Restrictions table. Hmmm.

So I run the query manually: EXEC DYNAMICS.dbo.zDP_SY02000SS_1 1, 'sa', 0, 2, 390

I then review the records in SY02000. It's been an eternity since I had to look in this GP 9 table, and everything is referencing dictionary resource IDs, so I don't know what any single record may mean.

And then I have a thought: What if, because I restored the client's Dynamics database, there are extra or invalid security restriction records that are causing GP to get confused?

Hmmm. How would I find such records?

I created a new GP user, "steve", and gave it access to the client's database without assigning a Class ID. I then queried SY02000 for both 'sa' and 'steve' to compare the record counts. 'steve' should have only default security records, so if my theory is right, I should see a difference.

Sure enough, sa had 29 more records than steve. So then I ran this self-join query to identify those extra records:

SELECT sy1.*, sy2.USERID
FROM DYNAMICS.dbo.SY02000 sy1
LEFT OUTER JOIN DYNAMICS.dbo.SY02000 sy2 ON sy2.CMPANYID = sy1.CMPANYID
AND sy2.DICTID = sy1.DICTID AND sy2.RESTYPE = sy1.RESTYPE
AND sy2.RESID = sy1.RESID AND sy2.USERID = 'steve' AND sy1.CMPANYID = 1
WHERE sy1.USERID = 'sa' and sy1.cmpanyid = 1 AND sy2.USERID IS NULL

I felt it was worth a shot to try and remove those records to see what happens. So I backed up the Dynamics database, and then ran this delete statement:

DELETE FROM DYNAMICS.dbo.SY02000 WHERE DEX_ROW_ID IN
(
SELECT sy1.DEX_ROW_ID
FROM DYNAMICS.dbo.SY02000 sy1
LEFT OUTER JOIN DYNAMICS.dbo.SY02000 sy2 ON sy2.CMPANYID = sy1.CMPANYID
AND sy2.DICTID = sy1.DICTID AND sy2.RESTYPE = sy1.RESTYPE
AND sy2.RESID = sy1.RESID AND sy2.USERID = 'steve' AND sy1.CMPANYID = 1
WHERE sy1.USERID = 'sa' and sy1.cmpanyid = 1 AND sy2.USERID IS NULL
)


I then reimported my packages into GP, and presto magic, everything worked fine again.

Definitely one of the more obscure problems I've run into, but resolving it before 8am was satisfying!