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…