Search This Blog

Tuesday, 12 March 2013

Should you move PCLaw from C-TREE to SQL?

In my prior blog post I compared effects of two offices of a firm running PCLaw C-TREE vs PCLaw SQL. The question is then should a firm implement / upgrade to the SQL or C-TREE version of PCLaw.
Whilst I am not a techy I have some experience working with a few CICs on PCLaw SQL set of issues and can give my view based on my own experience and requirements I have seen firms need.
CICs will give you conflicting answers and reasons for moving (or not moving) to SQL. One might then wonder: who is right and who is not? The short answer as one CIC put it is “there is no right or wrong answer..”. What works for one firm may not work for another.
Here is my take on it: As stated in my previous post, PCLaw just is not designed to work on SQL and can have devastating effects. There are however success stories of mid size firms using it well but my take is that if a firm feels it needs to move to SQL to get the benefits of SQL then it probably has reached a size it needs to take a holistic approach and assess its requirements. It may be that it has outgrown PCLaw. However if merely integrating with another software is the sole reason for upgrading to SQL version then it needs to explore other avenues.
My experience is that the C-TREE is better than SQL multiple times over because with C-TREE you have the following advantages (that are disadvantages of SQL):
·         Speed: C-TREE reports and routines are much faster than SQL.
·         Quick to implement and cost friendly: No techy /CIC needed and no additional cost outlay in terms of hardware/software.

·         Portability: PCLaw C-TREE database is easy to back up into a pla file and hence carry whenever and wherever one needs to and set-up. This has a number of benefits for a busy Accountant as stated below. SQL database on the other hand requires your Network Administrator or contracted / in-house IT staff to perform backups.

·         Creating a local set of books on a laptop or PC: For someone like me I carry a number of historic sets of books for different firms on my local drive. This allows access to historic or standalone set of books when needed. This historic data-sets has the following advantages: run and analyze historic reports via Excel, etc, trouble shoot problems, design new/edit existing reports/templates for later installation on a live system, test Security groups and restrictions before implementing on a live environment, test new functions & features using real firm data, review work performed by Accounts staff, etc.

·         Run VDI on a standalone: Sometimes running the Verify Data Integrity (VDI) routine on the live server may present problems. Quickly making a copy of the live dataset, locking it and installing on a standalone enables one to quickly run the VDI, perform a backup and restore the backup on to the live set.
I have always carried the data sets of firms that are on C-TREE whenever I have had to travel away. I ensure that the datasets I carry are most recent (a day old). One case I vividly recall was when I had to travel to a far away place where I could only get intermittent internet and email access. I was still able at my free time to generate all the Year End reports properly analyzed and email back to the auditors. All this without the need to remote in to the firm’s database (which would have been the case had the firm been on SQL). All I had to ensure was that I had a copy of the dataset with all the period and Year End adjustments complete. It was like carrying a brief case of accounts. The pla file was all I ever needed!.
I personally therefore would never touch a SQL database for the above reasons and also because of the inherent issues that the PCLaw SQL system is know for - data corruption, slowness etc. My mantra then; stick to the strengths of PCLaw and better the Devil you know.

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.