Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Use ComAPI in a web service

Status
Not open for further replies.

JoeAtWork

Programmer
Jul 31, 2005
2,285
CA
I'm trying to make a custom webservice using C# and Visual Studio .NET and a reference to the ComAPI. I am getting the following exception when I hit the Init method of the session object:

System.Runtime.InteropServices.COMException: 1.2750.6

The basic code is below:

Code:
			AccpacCOMAPI.AccpacSession accpacSession = new AccpacCOMAPI.AccpacSession();

			// DEBUG - the following line gives me the exception:
			//         System.Runtime.InteropServices.COMException: 1.2750.6
			accpacSession.Init("","AS","AS9031","53A");
			accpacSession.Open("ADMIN", "ADMIN", "SAMLTD", DateTime.Today, 0, "");

If I paste this same code in a C# Windows project (in a form), I do not get this error, the session opens without a problem.

Any suggestions how this code should be modified in a Web Service project?

My environment is:
Advantage Series Enterprise (Version 5.3A Service Pack 3)
Pervasive Database

I should probably mention that I am trying to call this code in the Application_Start event Global.asax.cs file.
 
As an update:

I just tried using AccPac's own web services (from within a C# Windows application), and I get an exception when I call the SessionOpen method of the ACCPACWebServiceSystemServices object. The exception is "System.Web.Services.Protocols.SoapException occurred in System.web.services.dll", and under additional info it says "server was unable to process request".

But the inner exception is the same as mine (COMException, 1.2750.6). If I look in AccPac's web service virtual directory in IIS I see it uses the ComAPI as well. Which makes me suspect that either it's an IIS configuration setting, or there's something in the ComAPI that makes it unuseable by web services.
 
Update:

I sent my test code to my client and had them install it on their IIS server. It worked there.

So it must be the setup on my machine. We are going to retry the AccPac install on my machine.
 
Update:

I have found I need to do two things to be able to open an AccPac session within my C# web service:

1. The ACCPAC folder under C:\Program Files has to be shared to allow network users to make changes to all files
2. I have to have AccPac open, which brings up the little "Pervasive Database Auto-Load" icon in the system tray. As soon as that icon disappears (i.e. when I close AccPac), my webservice gets a "Session could not be opened" exception. I suspect Pervasive can not be started when the call originates from the web service.

It would seem these are permission related problems. I am developing in WinXP Pro.

Any ideas on how I may need to configure user accounts, etc., to get rid of these problems?
 
JoeAtWork: I'd love to find out if & how you resolved your problems because they sound so similar to what I'm going through right now.

I had a feeling of deja vu when I read your posts... I'm creating a web app (15 aspx pages so far and still counting).

I tried using the Accpac .Net Libraries in order to create my session but they too failed on the init call with: "System.IO.FileNotFoundException: The specified module could not be found."

Regardless of what I tried, I couldn't get it to work. At one point I'd given up on using the .Net libraries and switched to the ACCPAC COMAPI but the only change was the exception (exactly the same) would get thrown when I tried creating the session object. I've tried using the Accpac XAPI library and the A4WASPLib but neither of them were any better.

Then I read your posts and tried what you suggested: I've created network & web shares of my accpac & runtime folders, I've launched accpac and had it running in the background when trying my app but it doesn't seem to make a difference. I still get the exceptions. I've taken the code that causes exceptions in my web app and ported it into a windows app and it works fine.

At this point I'm considering writing a DLL of my own that'll provide all the necessary interfaces and reference it in my web app. But I've never written a DLL in VB, I've never worked with Accpac in C++ (my other language) and I'm already a week behind schedule on this project... writing a DLL at this stage would just put me further behind.

 
Geak: at least I'm finally not just talking to myself in this thread!

The good news is I finally got my web service to work, and my client has been testing for the past two weeks and so far so good.

Regarding the folder sharing, I've managed to narrow that down to the AccPac folder under Program Files, and giving Read and Change permissions to just the ASPNET account. I guess the COMAPI needs to manipulate some files in there. By the way, I never even tried the .NET libraries, as they seem to do exactly the same as my code (i.e. wrap the COMAPI), so I figured I might as well stick to my more customized (and easier to understand) methods.

The requirement for having AccPac logged in while my web service was running turns out to only apply to my development machine. This was because my version of Pervasive was a workgroup engine (whatever that means), but on the production server Pervasive is a service and running all the time.

BTW, I also tried that DLL solution and it didn't work, I got the same errors as before. I think the problems we were having is entirely about permissions - our code is running under the ASPNET account so you have to make sure it has permissions to whatever the COMAPI needs.

Once I finally got my session connected, my development proceeded much better, although I did have to dodge a few more land mines. I suggest you look at the answers I posted to another thread (this was for a guy developing in VB.NET) here:
In those answers I detailed some of the other solutions I found for working with the COMAPI in a .NET environment.

One of the best strategies I have found is to do the following steps:
1. Record what you want to do in the macro
2. Through trial and error whittle down the VB code to the bare minimum required to do whatever its supposed (i.e. get rid of all those unneeded Process and Init calls)
3. Translate the code to your .NET language - I found this to be more or less a line per line translation

Good luck!
 
Well, I'm glad to hear you've gotten yours to work, unfortunately I haven't been quite so lucky. Unlike what you have set up my development system has Accpac EE 5.1, 5.2 and 5.3 on it (we've also got 4.3 and 5.0 but there isn't much demand for that anymore).

In order to get them all to work on the same system (and I suspect this has something to do with my "file not found" exceptions) we're using a series of batch files to switch from one version to another. I've created separate folders for 5.1, 5.2 and 5.3 and during installation of Accpac, instead of using Program Files, we used subst to create a virtual Q: drive pointing to the appropriate folder.

When we're done, if you want to run 5.1 a batch file maps the 5.1 folder to the Q: drive and then launches it. It seems to work fine as long as we're only using accpac or only using windows apps. By the looks of things, IIS and/or ASP.NET doesn't like virtual drives.

I've tried removing & adding the COMAPI reference again using it's real path but that hasn't made a difference. I've tried changing the reference's properties for Copy Local=True (figuring that if it doesn't have to go hunting for it, it should work fine) but that hasn't helped.

Incidentally, I also tried the DLL method. I created a simple DLL that exposes a session object and two properties (organization count and organizations). It works fine in a windows app but again when I tried referencing it in my web app it can't find (some) file.

I'm gonna have another look at the solution you used as well as the thread link you posted to see if there's anything else I can glean from them. But at this point I'm not holding out too much hope. If all else fails I'm going to call Accpac tech support to see if anyone there knows how to fix this.
 
Multiple versions of Accpac are very problematic. I suggest VMWare to ensure purely separate installations.

Jay Converse
IT Director
Systemlink, Inc.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top