Early in August I installed AR Service Pack 9.0B 2011.07.27. Everything seemed fine until now. We're trying to print our month end statements but it's not working. We select the statements for all customers and print to the printer. AR goes through the list of customers and on the second pass, it starts to print them. The first statement prints, then gives an "access violation" error.

I've confirmed there are no other open data files during this process. We've tried 2 different users work stations with the same error on both.

Can anyone help? How can I get the statements to print?

Hi Susan,

Softrak will let us know if they've encountered this before, but if this is not a known issue then ...

It would probably be useful to know if this is happening with the Sample Data as well. If Sample Data works with a Sample Data spec, try Sample Data with your live Spec and vice versa, Live Data with a Sample Data spec. This will help to narrow the issues down.

BTW - Sample Data statements work fine for me using that AR version

Pete

Okay so, Sample Data is Okay and so I ran an integrity check in AR and found 4 errors. Rebuilt and tried to print the statements again. Same error.

Hi Susan,

You may have read my original post before I edited it

Have you tried your Statements with a Sample Data spec and vice versa ? This would narrow down if the issue is with your data or your spec file - hopefully not both.

Maybe the spec. file has an issue - as that would be the lesser of the two evils. If so you may be able to restore an earlier version of the file that works.

Regards, Pete

Hmmmm maybe.. I'll try another spec sheet to see if it works.

I don't know how to see the history of what the 4 errors were in AR. Usually I run integrity checks from Data Care and I can look at the history. Is there a way to see the history of the integrity check done in AR?

Maybe I'll have to go to my back up before we started the month end. It's going to be a long night.

The DIC in both Receivables and DataCare writes information to ARINTERR.xxx in your data directory.

I'm backing up data now.. will look shortly and report back if I figure this out. Can you believe it was our biggest month of sales ever? But I can't complete the month end! Maybe the Adagio God's are preventing us... ?

Hi Andrew,

ARINTERR.dat is 0 kb. I opened it in notepad and it's empty.

If your extension is .dat then the file you are looking for is ARWINERR.dat.

But bear in mind that it overwrites every time so you won't be able to get a "history" of many checks, only the very last one run.

Pete

Hi, Susan,

Sorry, open the ARWINERR.dat file. DIC writes to that.

I ran DIC on the back up data (backed up before we started the month end). When I run an Integrity Check in DIC it reports "no errors". When I run an integrity check in AR, it reports,

"orphan gl detail have been found"
"checking transactions gl details... 4 errors found"
"Application integrity phase... 4 errors found"

This is what I rebuilt the last time, but it didn't help the statement problem.

I'm getting the same error (statments stop printing after the first one) even when printing to file (.pdf) and when using a sample spec.

Something noteworthy is that when I use the sample data (using our spec) and select 10 customers and print to screen, it sucessfully shows 1 of 10 pages and you can scroll through them. When I do the same thing with our data, it shows only 1 of 1 page. Same thing when I print to the printer, it says 1 of 10 pages using the sample data, but only 1 of 1 when using our data, even though I've selected 10 to print.

I got it!!!!!! Not sure why it worked, but I changed it to print to screen, then clicked "Preview" and it previewed correctly, 192 statements. So, I clicked print from there.

The bad news is, when I tried it again, it no longer works. Glad I printed while I had the opportunity, but I have no idea how to work around this next time.

Another problem is that even though I somehow miraculously got the statements to print, it did not ask me if everything printed okay and do I want to update the billing cycles and customer printed dates. Can I force it to do this somehow manually? Please advise.

Can I run the period end without updating the billing cycles? I'm not really sure what updating the billing cycles actually does, but I do need the transactions with zero balance to move to history.

Good morning.. I managed to print the statements again (to Adagio .pdf) so that I was able to get the message about updating the billing cycles and then I completed the period end. Unfortunately, however, I still have not been able to correct the problem. Since I don't want to go through this every month end, I would appreciate some direction on how I can get this resolved.

Hi, Susan,

Let's back up please. You were receiving an Access Violation error and you had integrity errors.

Access violation errors can be very difficult to duplicate and, as you found, you weren't able to in sample data. Did you check the ARWINERR.dat file to see the results of the last DIC?

In Adagio, you will never receive a prompt to clear when you print from the Preview screen.

Problems such as yours are very difficult to resolve on a forum soch as this. Perhaps, now is the time to contact your Adagio consultant.

Hi Softrak Support,

We were receiving an Access Violation error and we had integrity errors, however, the integrity errors showed up ONLY when running integrity check from within AR. When running integrity check using DataCare on the same data, it does not report any integrity errors. The integrity errors reported within AR are as follows:

"orphan gl detail have been found"
"checking transactions gl details... 4 errors found"
"Application integrity phase... 4 errors found"

Since these errors are only being reported in AR, I can only rebuild from AR. After rebuilding in AR and running integrity check from within AR again, it reports no errors.

The Access Violation errors are unchanged whether using the data with the AR errors or using the data after the rebuild that contains no errors.

One more note - I opened our data from a March 31 back up and it also has the same 4 errors reported in AR integrity check. We never noticed the errors were there because we do our integrity checks in DataCare, not AR. The errors have been there for months, maybe years, but we have not had any problems printing statements until this month. I can no longer print statements using my March data. ARWINERR.DAT has nothing in it except what is pasted below:

Checking Terms... OK
Checking Account Set... OK
Checking Billing Cycle... OK
Checking Transactions... OK
Checking Customers... OK
Checking Ship To/Contacts ... OK
Checking Cash batch 393 ... OK
Customer Filters ... Checked OK
Checking Customer Alerts ... OK
Checking Customer Alert Details ... OK
Checking Contact Alerts ... OK
Checking Contact Alert Details ... OK

The errors being reported in the DIC are related to the file that displays the GL distribution of a transaction. This won't impact statement printing.

I agree. On July 30, we did not experience any problems printing statements. The only thing we changed between July 30 and Aug 31 is that we installed the following:

Lanpak Upgrade: 9.0D (2011.06.30)
Ledger Upgrade: 9.0D (2011.06.29)
Receivables Service Pack: 9.0B (2011.07.27)
Payables Service Pack: 8.1C (2011.07.29)

Since these updates above, we noticed a glitch in Ledger. I used to print the batches to file (.doc) and overwrite the existing file, however this stopped working. It actually deletes the .doc file and leaves the status of the batches as open instead of printed. So, as a workaround, I tried printing them to an excel file and overwriting and this works fine. I didn't bother to report it since it's insignificant and I have a simple workaround. The only reason I mention it is that it is another strange printer behaviour that started after the above updates.

Hi Susan,

These errors may have been in the data for sometime, but the DIC was not check for this type of error (orphan records) before the update. DataCare may not have been updated for this error yet as it is a minor error and will not cause any reporting problem and is not related to the statement printing issue.

When you print your statements are you using any of the range(s) to control which statements are printing?
What is the sort order of the ranges you are using?

Hi Chris,

We normally sort by date order, but I tried document order as well and the result was the same.

I'm not sure if this has anything to do with it, but I just remembered one more thing that I did in August. In User Preferences on the Report Tab, I changed the Date format (Detail) to MM/dd/yyyy.

I just tested 3 times and had successful results by choosing "use selected specification" instead of "use customer specification", even though they both result in using the same spec. Our customers are not set up with a statement spec and I checked and confirmed they are all blank. The spec is specified by default in the company profile.

The font on the statements is different than it used to be, but "use selected specification" is definately working consistently.

Hi Susan,

While the output might be the same in your case, the forms printing process is completely different when you choose to use the customer statements. In that case, for each customer, the form name is inspected and the form loaded if it exists. If it doesn't exist, then the one in the company profile is used. The printer is then opened to find out what it is capable of (paper size, colour etc). The form is converted into a series of printer commands, the printer is closed and the memory used by the form is discarded. This process is repreated for each customer.

When you use a specific form for the entire run, Adagio Receivables can load that form, open the printer once, send all the statements to the printer in one job, and then close the printer and discard the computer memory it was using.

If either Receivables or the printer driver does not properly free the memory it was using to print the form, eventually your computer will run out of memory to use or reference some memory improperly. This will likely generate the error you saw.

We'll take a quick look to see if it is a Receivables problem. The fact that AdagioPDF worked properly, but the printer did not would tend to point away from Receivables having a problem.

It's weird that Adagio.pdf works because not only does it not work when printing to our main printer, it also does not work when printing to PDF Creator and not even when printing to Screen. Adagio.PDF is the only way I can print using customer specification. When I change it to "use selected specification", I can print to Screen, Printer, PDF Creator and Adobe PDF with no issues.

Thankfully, I don't need to use customer specification since "use selected specification" does what we need it to. The only time this would become an issue is if I needed to use different specs for different customers.