Importing into the Device

When you move an .mdb file to the device, it has to be converted. Because the H/PC database system is generally less robust than Microsoft Access, this is a lossy conversion. This section describes the conversion process in detail. The following table shows how data types are mapped from Microsoft Access to ADOCE.

Table conversion

A table is not converted or copied to the device if any of the following are true:

• All its fields are unsupported data types — a condition that would cause the converted table to be empty.
• The table is a system table. A system table is identified by its name being of the form MSYS*.

During conversion, table names are truncated to 31 characters. If you choose not to overwrite tables, and if a table already exists with the truncated name, then the last character is deleted and replaced with the numeric character “0.” Values from 1 through 9 are attempted in turn. If all ten tables already exist, then the table is not copied.

Field conversion

Field names map one-to-one because the supported length of 64 characters on .mdb files is the same on an H/PC.

Index conversion

All index names are truncated to 64 characters. The only index attribute that is copied is Ascending or Descending. For example, extra Access index information, such as Primary, Unique, and IgnoreNulls is omitted. Index names are not case-sensitive. Only the first field of a multicolumn index is indexed on an H/PC. Only three indexes are allowed. When you reach the limit of three indexes, the rest are skipped.

Indexes are created on the device in three stages:

• Stage 1

  Any unique index called “PrimaryKey” is processed first. If the PrimaryKey is a single-field index and the field is being copied, then it is recreated on the device. If the PrimaryKey consists of multiple fields, then an index is created for each field that exists on the device. These have “0”..”2” appended to their names, replacing the 64th character, if necessary. If this causes a naming conflict — very unlikely because there should be only one PrimaryKey index — then that index is skipped. Boolean fields are not indexed.

• Stage 2

  Unique indexes are created next. Unique indexes are not created if any of the following are true:

  • The indexed field is not being copied to the device.
  • The index name, when truncated to 64 characters, matches an index name that is already present.
  • The field already has an index on the device.
  • The indexed field is Boolean.
• Stage 3

  Non-unique indexes are created next. Non-unique indexes are not created if any of the following are true:

  • It contains more than one field.
  • The indexed field is not being copied to the device.
  • The index name, when truncated to 64 characters, matches an index name that is already present.
  • The field already has an index on the device.
  • The indexed field is Boolean.

These rules are designed to create the most useful indexes on a device. However, because device use is likely to be different from desktop computer use, users should examine the resulting indexes and adjust them to suit a particular application.

Conversion options

Windows CE filters may have user options. The following table shows the option that is provided for converting .mdb data.

Error Handling

Errors can occur when you copy data to a device. Errors typically fall into the following categories:

• Fatal

  Cannot continue to copy data to the device. For example, a fatal error occurs if the device is out of memory or if the communications link is lost. Users can correct some fatal errors.

• Informational

  The error does not stop the conversion.

The following process is used to handle the errors.

A log file named Db2ce.txt is created in the user’s partner directory, obtained from the registry, with the format described in the following table. It contains general status as well as all informational and fatal errors. If the file already exists, it is overwritten. If it cannot overwrite, then it tries Db2ce<n>.txt where n is 1..9.

If a fatal error occurs, an error is given to the user in the final dialog box, and the Db2ce.txt file is opened in the default .txt file editor. No attempt is made to clean up the H/PC, because it is not always possible.

The purpose of the log is to give users as much information as possible about the transfer process. Although most users never need to view this information, the log enables advanced users to investigate problems.

The following table shows the information that Db2ce.txt contains.

The following code example shows how the information is displayed in an ADOCE log file.

Sunday, June 14, 1998 3:17:56 PM, User: username, started sync

Database: C:\Program Files\Windows CE Services\Profiles\hpc2\db1.mdb

option: 1 - Overwrite existing tables
option: 0 - Keep this data base synchronized

Sunday, June 14, 1998 3:18:08 PM, Database transfer begun.


  Copying table Table1

    Processing indexes:
    Ignoring index for column 'Field5'. Not supported on the device.
    Index processing ending: No more indexes available.
    One or more index creations failed.

    SQL: SELECT `Field1`,`Field2`,`Field3`,`Field4`,`Field5`,`Field6`,`Field7`,`Field8`,`Field9` FROM `Table1` 
    Completed copying of 13 record(s).

Sunday, June 14, 1998 3:18:16 PM, Database transfer complete.
Transfer Statistics:
          1 Table(s)
         13 Record(s)
          4 Packet(s)
       6054 Bytes

If an error occurs, then the error text is placed in the log with any ODBC driver error information, even if a subset has been presented to the user on the screen. Statistics and closing information are placed in the log after the error.