The 7 Second Blog

I will start with this…. in general we do not have crashing issues. We carry lots of clients, many of which are on our fixed fee implementation….that means we support all issues – technical, set up and training. So if we had crashing, I would be busy all day dealing with it.

We have a standard methodology in dealing with issues that arise:

1. If Time Matters 9 – make sure the tmw0.ini file and the registry are not in conflict.
2. If isolated to a user, we copy settings from our model user.
3. If isolated to the program level, we toggle the setting.

So isolation works and many/most issues can be traced to the data in Time Matters…because your preferences are saved as data.

Ok.. so you have been there and tried that. Next you have to limit the data in Time Matters and you should start to look at the data that you cannot see from within Time Matters. Here is an example.. this is my personal database. You can see in the video below that there are many ‘users’ in my system that are not users here in our office. This could cause issues under certain circumstances.  You can also see that there are settings in the data that do not exist in our system. A good example is the quickbooks entry… no Quickbooks linked to Time Matters here.

CAUTION – THIS VIDEO SHOWS DESTRUCTIVE DATA PRACTICES. If you make a mistake there is no way to undo.  BACKUP, BACKUP, BACKUP and even then I am not sure I recommend a typical end user do this…

.

As we all know Time Matters as it ships has lots of power, but it is not harnessed. That power gets in the way and leaves the application in a state that is harder to implement and harder to use.  After years of consulting, I took some time off to readjust my philosophy and approach to Time Matters. That was the foundation of the 7 Second System.

Time Matters has to be:

• Easy to Use
• Easy to Understand
• Easy to extract data
• Even easier to extract key and critical data

It is.

If you have been using the shipping defaults (or any other variation or configuration) we make sure that you have not lost that time investment. We have automated data tools that can manipulate your data and conform it to our way of implementation.

All of our clients learn Time Matters in a few hours.
All of our clients immediately begin to use Time Matters.
We guarantee our training and implementations.

How do we do this? Take a look:

I am sure that it has happened to us at one time or another. A user leaves the firm.  What happens to their data? As we should know:

•  a user is a person that logs into Time Matters and
• a staff is someone that owns records – has a calendar, saves emails

When someone leaves, you have to deal with both the staff and the user. In this post I am only talking about the user.

What to do?

1. First you should disable the access for the user, you can just change the password if you want.
2. Log in as the user and deal with the records that are user related. Messages in the messenger, phone records flagged to that user and hopefully NOT but if you are using TM email.. clean out the Inbox.
3. I would then remove the user. Don’t fear, the records owned by the staff are still in place.
4. Deal with the records that have been orphaned in the database

What is orphaned?

Above in 2, are listed the records that are visible in Time Matters for that user…there is data that is not visible though and it should be dealt with.  A partial list:

• deleted messages
• user preferences
• user security
• auto entry forms for that user
• templates for that user
• trigger for that user
• autotxt codes for that user
• inbox

Is this a big deal?

If you are a very small firm, perhaps not. If you have any volume of users (and a volume that are no longer with the firm) it can. Remember Time Matters has a data table that holds information for all users/staff. If you want to look at your messages, the application has to look through everyone’s messages.   Another example, is to have your user preferences (appearance of screens, user configurations) the application looks through all user settings — including the users that are no longer at the firm.

I regularly see firms that have crashing issues that are data issues. A strong integrity check can increase program reliability.

How do I deal with this?

You could run a series of SQL queries and look for issues, if you knew where and what they were.  It is much easier to look at Sharpshooter (here) written by Steve Stockstill at DataEquity. It is one of the standard data integrity checks. As disclosure I am more aggressive than Steve and I delete more from the database than Steve would. Here is a video of the orphan user test. I show at the end how to delete the data.