GuestOffice and PMAC 2009

Written by Steve Stockstill

Many of you have been following Data Equity's development of GuestOffice, the internet based extranet for Time Matters Clients and Co-counsel. We are very pleased to announce the official product launch. GuestOffice will be available through our CIC partner network. We look forward to bringing our partners up to speed as soon as possible. There will be announcement in October with partnership details and free training opportunities. Please drop by the GuestOffice site for a closer look at this powerful new add-on for Time Matters.

Just a quick note to kick off the PMAC week. I look forward to meeting some of this blog's readers, business associates and Data Equity patrons at the 2009 LexisNexis PMA Conference. If you're going to be in Dallas, feel free to ask any follow up questions from the PracticeBetter.com blog posts. Better yet, on Wednesday afternoon I am presenting a session on Time Matters Integration with External Applications, stop in and say hello.

7 Steps to a Faster Time Matters - Step 7

Written by Steve Stockstill

This tip applies to virtually every list in Time Matters and can be identified and resolved very quickly.

Time Matters has a global list option (File/Setup/Program Level/List) which enables the display of a $ (dollar sign). When enabled, the functionality is to have a $ appended to the record status (when displayed in the list). This may be moderately useful depending on how you use Time Matters. On the other hand if you hardly notice the $ being there or don't care if it's there or not then RUN to the global settings and disable this database intensive option.

Why you ask is this so database intensive? For every row in your currently displayed list, Time Matters is looking in the Billing table for the existence of a Billing record that relates back to this entry in the list.

As an example, let's consider the Notes list. When we open the Time Matters Notes list every row in the list will ask the server if a Billing record exists for that Note. I for one don't bill my Notes so this will always result in wasted bandwidth and server. Even if sites do bill their notes it may not be imperitive to see the $ in the list, especially when you are working on improving performance.

This has been a fun series to write, stay tuned for the sequel.
--steve

7 Steps to a Faster Time Matters - Step 6

Written by Steve Stockstill

This performance tweak is specifically for the Calendar and is very simple to implement. This issue appears to have started in version 9 and is probably related to the numerous interface changes that were implemented in 9. In short, there is a performance degradation incurred by enabling the individual "Supported Records" in the calendar.The problem, as I see it is when the Supporting Records section is disabled, or turned off, the data is still being read from the server.

The good news is that you can simply disable each data type individually. Having disabled the individual record types, the Supporting Records section is not relevant and the performance degradation will not occur.

To quickly reactivate a data type, I would suggest adding the "View" option to the Calendar toolbar.

Inside Time Matters: Database Transaction Log II

Written by Steve Stockstill

I wrote an article last year regarding log file management as it pertains to Time Matters. The previous article was somewhat technical in nature and didn't properly cover specific recommendations for Time Matters. To a large degree that can be difficult to do, but for the vast majority I think we can set a baseline. From this baseline you can decide on a firm by firm basis what needs to be done specific to their needs.

The transaction log management starts and stops with two elements

The Database Recovery Model
Backups

As illustrated in the screen shot above, the recovery model is a database level option that controls how your transaction log will be managed. There are many articles written on how to manage this option and I encourage you to google "Recovery Model" if you're interested in the details. The growing size of transaction logs has been an increasing problem with the rise in popularity of SQL Server by small firms (without IT staff).

In general, if your database Recovery Model is set to Simple, you are done.There are no special precautions as that pertain to managing the log file, SQL Server will do it automatically. Though it can be modified, this was considered the norm for the stored procedure that Time Matters ships with.

The other common setting is Full Recovery Model (Bulk is rarely used). The Full Recovery Model requires a thorough understanding of SQL Server transaction backup theory. In General, a full database backup would be performed once a day, then several smaller, transaction log backups are performed throughout the day. This allows a backup to be restored to a specific point in time. All transaction log backups need to be present for this to occur. This is referred to as a "backup chain" because subsequent log backups are dependent on previous log backups, back to the point of the last full backup. It is important to note that truncating a log will destroy the log chain.

In keeping this simple, choosing the appropriate option comes down to on site expertise and the expectation for data recovery. If your client has on site IT staff that are capable of managing Transaction Log backups (and more importantly restores), this option provides the ability to recover data in a very granular method. If your client is comfortable with restores based on the last full backup, that is by far the most simple, low maintenance approach.

Converting from Full to Simple Recovery
If you have a large log file and want to move from Full to Simple recovery mode follow these steps:

Perform a transaction log backup, DO NOT use the TRUNCATE ONLY option.
Change the recovery model to SIMPLE
Perform a FULL backup
Shrink the Log file
Going forward, let SQL Server manage growing the file size, it will do a good job.

Staying With Full Recovery But Managing Log Size
If you have a large log file and want to continue to use Full Recovery, make sure you are benefiting from it.

Perform a transaction log backup, DO NOT use the TRUNCATE ONLY option
Shrink the log file
Perform a daily Full Backup
Perform several Log backups throughout the day
Going forward, let SQL Server manage growing the file size, it will do a good job.

(NOTE: Most problem stem from not performing step 4 so the log grows exponentially.)

My training comes from the school of hard knocks and a lengthy tenure on the Time Matters development team. Use this information as a guide to better understanding and always consult a database professional before jumping into critical areas such as this.

More Articles...