|
7 Steps to a Faster Time Matters - Step 4 |
|
Written by Steve Stockstill
|
|
There are several optional features in Time Matters that can greatly effect your performance. As you may remember, we previously covered "Keyword Indexing" in Step 2. In that article we learned that you could simply disable the option and immediately recover the performance benefit. Not all features are as simple and obvious to recover from disabling. Case in point: the Time Matters Exchange Synchronization. Disabling the Exchange Sync service or uninstalling the Exchange Synchronization Utility does not stop the ongoing database activities that are started when you install the Exchange Sync. The Exchange Synchronization adds nine database triggers to your Time Matters Database. Three triggers in each of the following tables: Contact, Event and ToDo. These database triggers perform extended data updates each time one of these tables is modified. That means if your Events and ToDo's are "following" you are performing one modify for the Event (or ToDo) table and two actions are initiated from the update trigger, one delete, one insert. Throw in the database maintenance, calculated field activity and the transaction log updates and you can quickly aggregate significant resource consumption. I mentioned Calculated Field activity. Calculated fields that are based on the Record Date must be recalculated when the Follow process changes the record date. These calculations are NOT ran in the stored procedure but rather a unique second process is spawned after Time Matters is initialized. This process will "recalculate" Calculated fields for each record type. Once again causing multiple database updates for each affected record. In summary, if you uninstall the Exchange sync make sure you finish the process by manually removing the after effects of the original installation. A new "Exchange Sync Status" test was added to SharpShooter version 1.14 to report the status of a given database's Exchange Sync. |
|
Inside Time Matters: Missing PowerView Tip |
|
Written by Steve Stockstill
|
|
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. |
|
Inside Time Matters: Exchange Sync Service |
|
Written by Steve Stockstill
|
|
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
|
|
|
Inside Time Maters: Calculated Fields |
|
Written by Steve Stockstill
|
|
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. |
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 Next > End >>
|
|
Page 1 of 8 |
