A PCLaw SQL Horror Story

In the past I have seen two incidences when a firm decided to migrate the PCLaw database to SQL. Both related to the same firm, with the first being for one branch and the second for the other. Different databases for different offices; different reasons to migrate to SQL; and all for the same firm.

The reason for the first office was to enable better data mining, extraction of reports for business intelligence, ensure data integrity and minimize data corruption issues. The upgrade was a disaster, crippling the Accounts office and within two days the database was reverted back to C-TREE.  All happy going from then on.

The database at the second office was faced with a forced upgrade situation imposed upon by the consultants who were engaged in implementing a DMS (Interwoven Worksite). Without upgrade of PCLaw to SQL they were not going to touch anything. And that was after the firm had signed off the purchase (of Worksite)! In a nutshell there was a complete disregard of the Accounting system for the sake of PCLaw integration with Worksite. Despite the risks presented in a “crystal ball” fashion and despite earlier warnings, the firm upgraded to SQL.

Fast forward two years later: The Accounts office on the C-TREE database continued with greater speed and efficiency whilst the other office on SQL began getting issues that got from bad to worse. To put things into perspective the branch on C-TREE database was consistent in finalizing its year end accounts & audit by  February while the other office had the worst year as it took 9-10 months in finalizing its Audit/Accounts.

So, what went wrong? The cause is “Interwoven” – yes as the DMS name suggests all issues interweaved from slowness in report generation, data corruption, errors prone balances which the Accounts team relied, to finalizing periodic and Year-End accounts and audit. The domino effect had disastrous consequences.

A short horror story and simply because unlike more mature programs (Worksite in this case)  PCLaw was not designed to operate on SQL. So, should a firm upgrade to SQL or stick to C-TREE? That is probably a topic for next discussion.

G/L Statements - Inability to search by Account Name

One of the important features introduced under G/L Statements is the ability to run reports for selected G/L accounts. However, currently only search by account nickname is possible. Searching by G/L account name is not possible. Unless users have crammed in their heads the G/L nicknames of the entire chart of accounts, printing a report for selected G/L account(s) can be a two step process: First, one would go to List>G/L Accounts search for the desired account. Then run G/L Statements and type in the desired G/L account nickname.

One would imagine this is an obvious enhancement needed but unless this search capability is added running G/L Statements may continue to be frustrating particularly for Accountants.