ACCPAC Session Not Initilaized 1

[SLICan]

We have a .net application which is written to communicate with ACCPAC 5.2. We use AccpacCOMAPI to connect to ACCPAC. Our problem is we are not always able to establish connection, sometimes we can, sometimes we cannot. We tried to trace the problem and found it stops at session initialization (AccpacSession.Init) and the message is "Session is not initialized". To fix this problem, we'd need to restart the .net application pool. Does anybody know how to fix the problem? Any reply will be greatly appreciated. Thanks.

 

[SLICan]

Thanks tuba2007, where do I get 5.2 web services info.

 

[Jay Converse]

There should be a CHM file in the DOCS\SM52AENG folder.

 

[ettienne]

If you are only checking customer balances why not pull it from the database?

 

[SLICan]

Yes, before it was using API and I changed already. I mentioned that just for example but there's still one part we use ACCPAC API. That is capturing supplier invoices. Since our PO and Inventory Control are on .net, we need to capture supplier invoice from .net and popuplate ACCPAC AP files thru API. And we have hundreds of supplier invoice every month. So if I couldn't find a solution I might need to use our own code to do the job. I know it's not suggestable but at least I managed to do it for AR transactions.

 

[ettienne]

I would use SQL queries on the database for the customer queries and then batch the other transactions once a day using the API, that way you do not continually open/close sessions. Customer queries will be faster using SQL and then obviously the API is better for posting transactions.

 

[DjangMan]

I'd do it that way, too (SQL -> Accpac). You can trap and handle the errors better, too.

 

[SLICan]

Hmm... sounds a good suggestion but I need to consult the feedback from user side. Since they get used to see the transaction is AP batch right after they click post button on web page. Beside they will alos question why we able to do that in AR (see the transaction in AR batch) but AP can't.

As I said, users are kind of losing confidense in IT in this area. It's tough...

 

[SLICan]

What do you guys thinks with the scenario that first time everything morning I always get the problem and need to rycycle the application pool.

 

[DjangMan]

Not sure. You indicated that the problem appears to be just with your AP integration and not with your AR integration - right? If that's the case then I would suspect the AP code needs some adjusting or bulletproofing.

 

[ettienne]

It would be impossible for us to say why it happens when it happens.

 

[ettienne]

I'm an accountant and a programmer and I have been doing this for nearly 20 years and written hundreds of system integrations, I have even been involved in the development of some of the Accpac modules (GL Consolidations and Inter Company Transactions). With that in mind my best advise is always to batch your AP & AR transactions and create one batch at the end of the day. Sure it looks cute and cool to create batches real time, but there is no compelling reason to do that from either an accounting point of view or end user point of view. The less you interact with the Accpac side the better. Just my 2c...

 

[ettienne]

Another comment is that I have another client that does more or less the same as you do, they use .net and create AP & AR invoice batches, customers and vendors all day long and they do not run into any issues.

 

[Jay Converse]

Yah, Ettienne smart! Him have good ideas, me like.

 

[SLICan]

Hi DjangMan,
The way that I did in AR was create a few stored procedures in Pervasive and connect to ACCPAC using .net connection string and invoke the SP to populate the files. Of course, this is kind of risky if it was gone thorough understanding about the update logic.

 

[SLICan]

Ettienne,

I agreed with your point. By the way, you said one of your customers is doing like we do, do you mean real time update to ACCPA?

 

[DjangMan]

So for AR you're updating the AR tables manually? If so, I respectfully call you crazy. Not that it can't be done but it just seems too risky.

You can populate some tables via ODBC and have a timed/scheduled procedure that looks in the tables every 5 minutes and puts the data into Accpac then.

 

[ettienne]

Yes, the client is pushing data to Accpac realtime as info is entered on a website, they are opening/closing sessions and creating batches all day long in about 10 different Accpac companies.

 

[SLICan]

When you say manually, do you mean fill data column by column and table by table? It you meant so, that totally wrong. I have stored procedures to update ARIBH, ARIBC, ARIBD & ARIBS and these SP are fired with my .net vb.

 

[DjangMan]

By manually I meant are you using the COMapi layer or are you executing SQL INSERT statements? It looks like you are via your stored procedures.

If you're not upgrading Accpac and you've sorted out updating all of the appropriate tables then that will run faster than going through API. If you do upgrade then you end up having to learn what new tables and fields need to be updated.

 

[SLICan]

I see, cool. As you suggested, I would look into batching before pushing to ACCPAC but then it will require some effort like to identify records that are batched to be post etc.