I was recently helping a fellow consultant identify why a PowerView wouldn't show up in the list of available PowerViews (list/options/powerview/add).

As it turns out the powerview contained a reference to a list type that was disabled (program level/lists/uncheck). What makes this unusually rare and difficult to identify is that PowerViews normally do not contain references to a broad array of data list types.

Here's a simple way to improve the reliability of your Time Matters Exchange synchronization. When the Exchange sync component of Time Matters is installed on the same server (computer) as the SQL Server, the Exchange sync service should be configured to depend on (wait for) the SQL Server. Some software applications have this functionality built in, for example, MobileTM does this for you automatically.

You can do this manually in just a few short steps. If you are comfortable modifying the registry, just follow these steps:

1) Determine the name of your SQL Server service, the default is MSSQLServer but if you have server instances, the service name is MSSQL$[instance_name] for example, MSSQL$SQLEXPRESS.

2) Launch the windows registry editor

3) Locate the Exchange Sync service entry as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LNFOExchangeSync

4) Add a new registry key for the LNFOExchangeSync service:

Select Edit menu (or right-click service name), select New, Multi-String Value, name the new key "DependOnService"

5) Double-click the newly created registry key then enter the name of your SQL Server service (from step 1) in the entry and save.

The results should look something like this:

Windows Registry Dialog

Service Properties Dialog

Calculated fields were introduced circa Time Matters 4. A calculated field is a field type defined in the field properties of the form style and has its value derived from up to 4 other fields. The result can be formatted as a Text, Number, Money, Date, and Time display formats.

Calculated fields in Time Matters are much different than other software applications. Most applications treat calculated fields as virtual information, derived at runtime. In contrast, Time Matters stores the result of the calculation in the database and does not continually calculate the value at runtime. This method has its share of cons but some very significant pros.

The Pros
- These fields can be sorted in data lists
- Filters can use these fields
- External reporting tools can use these fields

The fact that calculated fields are pre-calculated and stored in the database creates more opportunities to use these fields in runtime operations.

The Cons
- Data cannot be changed from outside the application
- Execution of the calculation can be time consuming
- Calculations are not enforced

It is very important for consultants to understand that changing Time Matters data without using the DataLink API will result in uncalculated data. It’s possible for calculated fields to get out of sync or not current. There are at least five actions that instantiate calculated field updates. They are:

1. Creating a new calculation
2. Revising an existing calculation
NOTE: When adding a new or revising an existing calculated field, a  prompt will ask if entire database should be recalculated. If no is selected, the status of the calculation in the remainder of the database will be unknown.

3. Anything that changes a record from inside the program: open/save, process change, trigger, etc.
4. SQL stored procedures know that when they change data that calculated fields need to be updated. For instance, the Follow Flag stored procedure checks to see if a record’s date was changed and if this record has a calculated field on the date.