Tuesday, April 25, 2006
SOLVED!
Almost three weeks ago we started working with Juris support on the problem of edited pre-bills generating an ambiguous error when saving. This did not happen in all instances, but ultimately was putting the firm in a position of not being able to do cash receipts or billing.
We had already had a traumatic time of upgrading the the newest incarnation of Juris, after a few years of essentially smooth operation. The trigger for upgrading was the need for an electronic billing format not usable in the old version, based on the needs of one modest client. Had that not come up, we would probably still be waiting to upgrade. Which, actually, I didn’t realize we were.
Anyway, the upgrade had gone badly, wasting a weekend for me and having to be completed on Monday after support was available. Then the upgrade reset some defaults and none of us realized it, so half a month of timekeeping entries got duplicated as many as several times each. They are still working on purging the duplicates.
Then the pre-bill editing problem.
We worked with one support guy who covered seemingly everything and ended with the edict to upgrade to SQL Server. The proximate cause of his decision was that the combined data and logs from MSDE were over the limit of 2 gigabytes. He insisted there was no way to trim this, and that we should have received warnings at 1.6 and 1.8 GB but we must have turned the warnings off. I did a Verify and Shrink on the data, which truncated the logs down to zero and made the whole database about 1.5 GB, well within range.
What bothered us was the assumption that it was all us. If you have Spiffy Program version 2 and it works great, then you install the upgrade to version 2.1 and it barfs, how can it be that suddenly your machine is misconfigured, lacking memory, or not using an adequate database? Well, it could be, with dramatic enough changes, but you, the vendor, would have loudly warned the customer of the changes in requirements before insisting they upgrade.
In fairness, we should have SQL Server, and this has helped me emphasize the need to upgrade soon, like this year. MSDE really is going to be outgrown before much longer. In fairness, 512 MB really isn’t much RAM for a server anymore, and it’s looking like the updated MSDE is what’s hogging most of it. In fairness, while they encouraged us to save money by using Windows 2000 Professional on our “server,” that was never as ideal as using the full server OS.
So we ended up back with support, with a woman there who was perhaps more helpful, and certainly more willing to dig in and make sure it was resolved. We retraced some steps. We uploaded them our data when it looked like corrupt data had to be the problem. That was a breakthrough, because it proved the data was fine.
Finally, after looking at SQL error logs again, she had a senior tech Webex to our server, which is something I’d expected them to do sooner. It was a pleasure watching him fly around the system, looking at event logs, SQL logs, file versions, and various settings at high speed.
It was almost a let down in the end; an anticlimactic (as opposed to being against the weather in an anticlimatic way) result. The problem?
msxml2.dll
Ours was a few notches below the minimum required. Why did their distro or Windows service pack or something not update it if there is a newer one? No idea, but duh.
In the end, the resolution was as simple as renaming and unregistering msxml2.dll, copying a newer version to system32, registering it, and (after a courtesy reboot to clear the memory and just because it felt too simple otherwise), testing the prebills that would not save edits previously.
That worked. Yay. Let’s not do that again soon…