Day-end processing error on P/O step 2

[Warren S]

Hi

Please can someone assist

I seem to be having a problem when doing a day end in accpac keeps failing on the P/O step with the following error

Description: Purchase Order Posting. Database error (operation=GET-GE, error=2).
Source: 22:38:12

RVSpy Details

Accpac p/o version 5.2a
Pervasive Workgroup engine 10.1

Let me know if you need any additional info

Thanks

 

[ettienne]

You have bad PO data.

Sage 300 Certified Consultant

 

[Jay Converse]

In Pervasive, error=2 can be very bad. I hope you have a good backup. Pervasive rebuild might fix it, but your odds are low. Accpac Dbdump/Dbload also might fix it, but YMMV.

 

[Warren S]

Hi Ettienne

anyway I can find out what PO data is Bad

Hi Tuba

Busy with a DBdump currently

Thanks

 

[Jay Converse]

The RVSPY log will tell you, look farther back in the log for 3 or 4 ERROR lines in a row.

 

[ettienne]

You need to find the FIRST error in the RVSPY log, not the LAST error.

Sage 300 Certified Consultant

 

[ettienne]

But once you find the error there is not much you're going to be able to do about it, since error=2 is bad data. In other words you could have a damaged table.

Sage 300 Certified Consultant

 

[Warren S]

Hi Ettienne

I found the problem table was the POPORI table I checked the table and there was only 6 records in it tried deleting the records still same problem I then replaced it with the blank table out of the sample database and all is now ok with the dayend processing completed.

They were also getting a insert error when they were trying to post a PO this is also now gone.

Just a bit unsure what problems this is going to cause me in the long run I now the table holds the PO posting but is this just a temp table until day end is done or does it contain all history

Thanks

 

[Jay Converse]

You are one lucky mo-fo. POPORI is the "pending day-end purchase order header" table. Indeed, it's a temp table that's populated whenever you post a PO, and cleared at day-end, so replacing with an empty version is a valid option.

 

[Warren S]

Thanks Tuba

I think I was lucky on this one as this is not one of my sites so I am not even sure if they have backups in place but from what I have heard about the previous support they recieved I highly doubt.

Needless to say I have now created a backup of the database and busy running some integrity check now on a backup database I have moved to my servers and are finding massive errors in all the modules think this is going to be a fun one lol.

Regards have a good evening and thanks for the help

 

[Jay Converse]

Just thinking about Pervasive errors like this gives me PTSD, I still remember all-nighters recovering data. All it takes is one user doing Ctrl-Alt-Del during posting, or a NIC hiccup, and Pervasive tables get corrupted. I'm so glad everything is in MSSQL now.

 

[ettienne]

The problem is that there were invoices posted in PO that will now never find their way to AP.

Sage 300 Certified Consultant

 

[Jay Converse]

Maybe, maybe not. POINVI wasn't corrupted.

 

[ettienne]

POPORI has a list of transactions that need to be processed in POINVI, without POPORI day end processed does not process those POINVI transactions and they do not make it to AP.

Sage 300 Certified Consultant

 

[Jay Converse]

Not true, I just tested it in SAMINC. A new PO invoice created a record only in POINVI, not POPORI. In fact, I deleted the three old POPORI records that were there, and day-end correctly still correctly processed the invoice.

 

[ettienne]

It may have changed in the newer versions then, in the older versions the AP invoice would be missing. Interesting.

Sage 300 Certified Consultant