How To Make PocketPC PDB Apps Close Faster

Problem: How To Make PocketPC PDB Apps Close Faster

Solution: Satellite Forms Windows Mobile/PocketPC applications that use the PDB database format (which is highly recommended over the CDB database alternative, see How To use PalmDB (PDB) tables in a PocketPC application) can experience delays when closing the application. This delay occurs when cached table data is committed back to storage as the application closes. There are some techniques you can employ to speed up the application closing process, explained below.

Overview: The key to speeding up the closing of PocketPC PDB applications is understanding how Satellite Forms uses Table Flags. Table Flags are attributes that you can assign to individual tables in your application that cause the SatForms runtime engine to treat the table in a special manner. The Table Flag is a numeric value that determines special behaviours of that table when it is in use on the PDA by the Satellite Forms runtime engine. For example, one of the possible table flag values indicates that the table is Read-Only, and the runtime engine therefore prevents any modifications/additions/deletions to the data in the table.

The Table Flags for each table are initially defined in the Table Editor (Layout tab) in App Designer, where you can set the available flags using checkboxes. The NoAutoCommit flag option is new to the Table Editor in App Designer in SatForms 7.1, but support was added for this flag to the runtime engine and SFConvertPDB utility starting with SF Patch 70003. When you compile your application, the table flag values corresponding to the selected options will be saved into the PDB table header. Additionally, flags can be specified using the -CreateFlag parameter of the SFConvertPDB utility. Each table can have different flags as they are assigned on a per-table basis. The current supported table flags include:

Flag value	Flag name	Flag description
0	No table flags	No special table behaviours - regular read/write table. The PocketPC runtime engine will automatically commit the table to storage when the app closes, regardless of whether any records were modified/created/deleted. This is the standard behaviour.
1	Backup	The table will be backed up at Hotsync (PalmOS behaviour only). This flag currently has no effect on the PocketPC platform.
2	Read-Only	The runtime engine will prohibit table record modifications/additions/deletions and will only permit read access to the table data. The PocketPC runtime engine will not commit read-only tables to storage on exit, and thus will close read-only tables more quickly than standard read/write tables.
4	Autoname	The desktop table name will automatically match the logical table name (this is the 'Link table name to filename' option in the App Designer table editor). This table flag is used by App Designer only and has no effect on the PDA.
64	NoAutoCommit	This is like a cross between a standard read/write table and a read-only table. The runtime engine treats this as a standard read/write table while the application is running, allowing you to modify/create/delete records. However, the table will not be automatically committed to storage when the app closes, thus any changes will not be saved. To save the data before closing, you must explicitly commit the table data to storage. This flag is implemented on the PocketPC platform only, and is ignored on the PalmOS platform (the PalmOS runtime treats it is a standard read/write table). The NoAutoCommit flag permits tables to close more quickly by not automatically committing them to storage when the app closes, like a read-only table.

Some table flag values can be combined, while others must be exclusive. For example, the Backup, Read-Only, and Autoname flags can all be present on a given table, and you would combine those flags by adding their flag values together. The Read-Only and NoAutoCommit flags must be exclusive to each other: do not combine them together.

Implementation: With an understanding of how the SatForms PocketPC runtime engine uses table flags, strategies to speed up the closing of applications become readily apparent.

The first and easiest approach is to make sure that any tables in your application that will never be modified are marked with the Read-Only table flag. The runtime engine will not commit read-only tables to storage when the app closes, because they logically should not have been modified in any way, thus read-only tables will close instantly. This is an especially important consideration for large information reference type applications (for example a medical reference database), because the length of time it takes to commit a table is directly proportional to the overall size of the table. It is also something to consider for smaller tables in non-reference type applications too, for example a list of non-modifiable items used for a droplist. Set the Read Only checkbox for the table in App Designer, and be sure to also set the proper -CreateFlag value if you use the SFConvertPDB utility in your desktop sync application.

The second approach is a bit more complex, and that is to use the NoAutoCommit table flag on tables that you may or may not make modifications to while using the application. A NoAutoCommit table may be modified by your application just like a regular read/write table, but the runtime engine will not save those modifications when your application closes. If you want to save the changes in that NoAutoCommit table, you MUST commit the data using the Tables("tablename").CommitData method prior to the application closing. Since the runtime engine will not automatically commit the NoAutoCommit table data to storage when it is closed, it closes instantly just like a Read-Only table. NoAutoCommit tables therefore give developers an option that can reduce the delay when closing an app, in addition to the option of using Read-Only tables. For example, if your app includes 10 NoAutoCommit tables, but you have only updated 2 of those tables when your application goes to close, you can commit those changes on the two tables by calling the CommitData method, and leave the other 8 tables to close without being committed. Your application would then close more quickly than if all 10 tables were committed to storage on close. The added flexibility of using NoAutoCommit tables does come with added responsibility: you must explicitly handle the task of committing your modified data tables to storage if you want to preserve the changes.

Keywords: commit, table, database, PDB, speed, close, commitdata, SFConvertPDB, flag, createflag, read-only, noautocommit

KB ID: 10075

Updated: 2007-09-13

Satellite Forms KnowledgeBase Online

Satellite Forms Website Home