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.