Class not registered error on Init event 3

[JoeAtWork]

Me again.
I've deployed my ASP.NET timesheet app on the production server. I use the AccPac COMAPI to retrieve data such as employee names and earning codes. Problem is, it isn't working on their server.

When my code gets to a Session.Init method, I get a "Class not registered" exception. The error suggests the COM library isn't registered, but AccPac works fine on it. Also, I wrote a little VB program that opens a session, and that worked fine. So it seems to have to do with being in the context of an ASP.NET app.

In a previous web service app I wrote, I had a similar problem until I gave modify writes to the ASPNET machine account to the C:\Program Files\AccPac directory. I applied the same solution this time but that did not help. One slight difference is the AccPac directory is on the D: drive - but I can't see that as being a problem.

My version of AccPac is Advantage Series Enterprise Edition (Version 5.3A Service Pack 3), theirs is Sage AccPac 200 ERP (Version 5.3B).

One thing I find curious, I determine what AppID, ProgramName, and AppVersion values to give to the Init method by opening the macro window, and checking what these properties are for the Application object in the Immediate Window. The settings appear the same as my version, but why would their Application.AppVersion return "53A" when their real version is 5.3B?

I have another thread that shows my code and the error messages here

http://www.tek-tips.com/viewthread.cfm?qid=1302646&page=1

 

[ettienne]

FYI the Session.Init AppID, ProgramName and AppVersion can be anything really, it does not matter. We stick to "XY", XY0000", and the actual SM version - "53B" in your case.
Can you run a macro on that server? It could be that the COMAPI has not registered properly, run the VBA install from the Accpac CD or the WSSETUP folder.

 

[JoeAtWork]

Thanks for following up on this, Ettienne. I ran a macro that changed the description of a timecard on the server, so by now I'm pretty convinced the COM library is properly registered and the error message is a red herring.

I'm going on the theory that this is a permissions issue. The admin installed the web version of AccPac last night, to see if that would help. I noticed it mapped it's virtual directory to a shared folder (\\ServerName\D$\WebApp) instead of directly like I did mine (D:\WebApp). So I tried the same thing - but that broke the connections to my other databases! Apparently it doesn't impersonate as the IUSR_ account when I map to shared drive(?)

 

[zemp]

It might be a version conflict. Especially between ERP 200 and ERP 500. You might have to make sure that your code is referenceing the correct verion (200 vs 500) of the COM object.

zemp

 

[ettienne]

ERP 200 & 500 does not make a difference, it's identical.
You have security issues mate.
\\ServerName\D$\WebApp is seen as a different domain, and MS will block certain things from running for security reasons.
Get it installed to a local drive and at least you do not have to deal with the security issues.

 

[zemp]

Sorry, but they are not. I have come across a couple of examples where Accpac claims that things are identical and haven't changed but that's just not true. Upwards of 98% the same I can agree with, but not 100% identical.

I have seen this with COMAPI UI controls in 200 vs 500 and in the xAPI (which they were apparently not touching or changing anymore when they moved to the COMAPI) with 5.2 vs 5.3 and now 5.4. It is not the code that requires changing but rather the control or file reference itself.

Sorry I don't have specifics at the moment, I'm not at my development machine.

zemp

 

[ettienne]

There is no difference between 100, 200 & 500 COMAPI for the same version - which is what I said.
There is a difference between versions (5.2, 5.3, 5.4 etc).

 

[zemp]

I understood what you said. I was just pointing out another example, with a different file (A4WCOMM.dll), where Accpac says there is no difference but actually there is. Because in the xAPI example there was no issues or problems from 4.2 throught 5.2 and then with 5.3 there were compilation issues.

I apologize if I wasn't clear in my explanation.

zemp

 

[JoeAtWork]

An update on the situation.

Last night, for the heck of it, I logged into the web app, and lo and behold it was now loading the AccPac data!

This morning however I am back to the same problem with the same error message (weep).

Now I have to play detective to find out what the difference was last night at midnight and this morning. A logical explanation might be that users were using up all the licences (they only have three), but I know for a fact that there was license available every time I tested.

Maybe some sort of timeout issue that doesn't occur when there is less user activity?

Any fresh perspectives?

 

[JoeAtWork]

So this will be the thread where you get to see a programmer gradually loosing it.

My next test: create a .NET Windows application that uses the same DLL and calls the same method (which retrieves a list of Employees) that causes the ASP.NET exception. This was mostly to prove to myself that this wasn't a .NET/ComAPI issue. The Windows app worked just fine - the employees got loaded into my listbox.

The one thing I noticed is the first time I called the method, the Pervasive splash screen came up for a second. Every subsequent call this didn't happen. But if I closed the Windows app, then started it again, and called the method, then again the first time the splash screen displays.

Just wondering if this might mean I have to set some sort of permissions with Pervasive for the ASPNET account?

 

[ettienne]

You do not have to set anything with Pervasive. The splash screen pops up because the Pervasive client is establishing a connection to the DB, it will only show once per session. You can turn off the splash screen in PCC.

 

[JoeAtWork]

It's solved!

A friend of mine with more experience deploying ASP.NET apps saw what I couldn't see.

Basically, in the application pool that the web app was assigned to, I had set the identity to the "IWAM_" account. He set it to "Local System", and this is all that was needed. So simple!

Stars to those who took the time to offer their advice.