Our accountant’s computer has been dog slow for the last six or so months, so after going through the lengthy process of spec’ing a new system and getting the purchase approved, I was finally able to get her a replacement. The new system, with massive amount of RAM and a screaming processor (with a nice SSD to top things off) truly is a thing of beauty, however we ended up running in to a rather large problem.

Because the new system runs Windows 7 x64, we had to upgrade our slightly-old copy of Pervasive SQL 10 to Service Pack 3. Although this seemed to work fine with ACCPAC initially, we quickly discovered all was not well.

Case in point, when trying to print an invoice with a custom Crystal Reports template, ACCPAC would simply throw the following error:

not enough memory for operation

Searching Google got me nowhere. The few references to that error and printing only spoke of issues with Terminal Server environments, and none of the suggested steps worked. After a few hours of fighting, though, I had the bright idea to try using one of the stock invoice templates.

Go figure, it worked.

As it turns out, the CR templates we were using dated back at least six years, and had been created with a copy of Crystal Reports 7 (dating from 1999!). So, we downloaded a trial copy of Crystal Reports 2011, re-saved the templates, and the memory error disappeared without a trace. There were a few issues with the templates (some fields refused to populate), but some manual adjustments (read: copy and pasting sections for the working stock ACCPAC templates) solved that as well.

TL;DR Version: If you get the above memory error when trying to print from ACCPAC using custom Crystal Reports templates, try re-saving them with a newer version of CR. Apparently that’s all it takes.

I came back from vacation the other day to find that some computers on our primary domain (example.local) were unable to access shares on a secondary domain (test.local) located in another building, accessed via a wireless link). When attempting to open the share (or just browse to the Domain Controller), the following error would appear:

Share Error

"There are currently no logon servers available to service the logon request."

Google’ing did no good, as there were only vague references to DNS issues and WINS servers (the later of which we don’t use). As nothing had changed in the environment recently, I was at a bit of a loss. I could ping the DC (Homer) in question, and even RDP to it, but I couldn’t for the life of me access the share. NSLOOKUP behaved normally, but then I had a thought — the DC that I couldn’t access was also acting as a DNS server (the primary one for test.local) with example.local as a Secondary Zone (which, of course, contained the DNS entries for the computers that were having trouble accessing the secondary domain). When I loaded the DNS manager and clicked on that zone, I was immediately greeted with an error stating the following:

DNS Error

Turns out, there *was* a DNS problem!

The problem was that I had removed a DNS server over a year ago and it was still referenced as the primary DNS server for this zone. For some reason, the Windows DNS service had just now decided this was a problem and stopped grabbing copies of the zone from the functional secondary DNS server.

To fix this, I simply right-clicked on the zone, chose Properties, and then removed the offending server IP from the General tab and updated with the correct servers and order. As soon as I finished, the computers had no trouble accessing that DC again. Magic!