I have a couple of WennSoft customers in my fold, and they often pose some of the most challenging issues to resolve. For those of you who are not familiar with WennSoft, you can find out more about their products here. For those of you who are already – and reluctantly – aware of these add-ons, this post is for you.
GP service packs used to make me nervous, but they are almost effortless when compared to the issues I have encountered in applying WennSoft service packs. Most recently, I took a customer from WennSoft Classic 2010 SP1 to WennSoft Signature 2010 R2 SP1. This service pack contained 193 fixes to prior releases of the product and was compatible with GP 2010 build 1914.
I tried to anticipate (based on prior experience, of course) any obstacles that might come my way on a Saturday, when WennSoft support would not be available. I requested and safely tucked away the new registration keys that I knew would be required; I requested additional information from WennSoft regarding any “gotchas” that might come my way and any additional downloads that might be needed; I had the customer’s IT department download the appropriate files and place them on their server, and I double-checked the versions; I exported all modified reports for GP and WennSoft to package files; I backed up the GP code folder, etc. We planned a back-up schedule after close of business on Friday and I coordinated with IT to ensure that everything was ready.
After running the GP update Friday evening and verifying that it was error-free, I ran the WennSoft update utility. As it was already late, I left that process running and went to bed. Of course, in the morning I was greeted by a not-so-clear error message referencing a table that had updated sucessfully. So after some research and pondering, I decided to give the update another shot. It completed without error. Yippee!
Unfortunately, my joy was short-lived. I completed the update steps, took backups of the databases, verified that reports still worked, etc. Then I notified the customer contact that the update was complete, so that she could do some testing before we updated clients. This is all standard procedure, of course. I had updated a single client and documented the steps so that the customer could complete the remaining workstations after testing. I then moved on to deploying refreshable Excel reports, GP SRS reports and WennSoft SRS reports, and setting the necessary security for users to access them.
Monday morning we found out that the testing was not thorough enough. Users encountered errors when opening some windows, errors that indicated that tables had not been updated. I’m sure you’ve seen this dreaded error message before: “Number of results columns doesnt match table definition.” The customer contacted WennSoft directly for additional assistance and users continued to do their work in the system. We knew at this point that a rollback of 12 workstations and server would be quite time-consuming and that most of the system was operational, so my customer decided to trudge on. A few hours later she received some guidance from WennSoft regarding a maintenance utility that would show us which tables did not update. My response, of course, was to immediately run the maintenance utility, all the while wondering a) why does this not automatically run as a final step of the update process and b) why does it require a password? Putting my frustration aside, I proceeded with the troubleshooting. There were 14 tables that were not updated. After another few hours of back-and-forth between my customer and WennSoft support, they offered to update the tables manually for a consulting fee. My customer asked if this was my recommended course of action, and I replied that I would do it for them, as I knew exactly what needed to be done to correct this error.
The answer was obviously to copy out the contents of these tables, rebuild the tables and associated stored procedures, then import the data back into the newly updated tables. Fortunately, only six of the tables contained any records. The other ones were empty and could simply be dropped and recreated. I used the handy SQL maintenance window in GP to take care of this, beginning with the empty tables, then used the WennSoft utility to verify that the tables were at the correct version. Three hours later, all the tables were rebuilt and the data back in place, and no further errors have been encountered in the system.
Harrowing experience? Yes! Rewarding? Absolutely!
Q Factor's Blog 