Principles for conversion

• You must have an "interpreted" version of the database (xxxx.4DB file for the structure, xxxx.4DD file for the data, .RSR and .4DR for versions prior to 4D v11 - see "Conversion" documents for older versions), as well as a Super-User password to perform a conversion;

• Make a copy of your database before conversion;

• Perform a syntax check. Even if you do not want to compile your database, this check can help warn you about possible errors;

• Use the Maintenance and Security Center to check and repair the structure and data;

• Check whether you have any PICTs using the GET PICTURE FORMATS command and convert them using the CONVERT PICTURE command .
  As of 4D v14, by default QuickTime codecs are no longer supported. For compatibility, in a 32-bit version, you can re-enable them in your database by using the QuickTime Support selector for the SET DATABASE PARAMETER command . Changing this option requires restarting the database. Note, however, that QuickTime support will be permanently removed in future versions of 4D.
  To convert obsolete format images: see Conversion of picture type.

• (Optional) Possible to implement primary keys if data journaling is needed (starting with version 14) (see Primary keys in the Design Reference manual). It is strongly advised to set them up, but this can be done after the conversion.

• Since 4D v13.5, it is mandatory for Unique fields to be indexed. You will no longer be allowed to create/modify any records for a non-indexed Unique field: attempting to save the record will generate an error (-9998 Unique record exists, 1088 Index is invalid or missing).
  To create missing indexes, or generate a disk file listing all the non-indexed fields, refer to To create missing indexes.

Databases created with version 16 of 4D or 4D Server (as well as ones created in v11, v12, v13, v14, and v15) are compatible with 4D version 17 (structure and data files). You can convert any interpreted structure file. To do this, just launch 4D v17 and open your structure file (xxx.4DB file) in interpreted mode.

• Structure File Conversion (.4DB)

A dialog informs you of the conversion of the structure file and, depending on the starting version, the conversion of the data file:

Your structure file is converted to 4D v17 and can not be opened in a previous version.

• Converting the data file (.4DD)

Data must be converted for 4D v14 and earlier databases. In this case, a second dialog appears:

This data file is then converted to version 17, but can still be opened and used with 4D v15 or 4D v16.

The data does not need to be converted for 4D v15 or 4D v16 databases.

• Setting up log file dialog

If the primary keys are not in place, 4D will ask you to do so by displaying the dialog below:

It is advisable to set up  primary keys ("Use Wizard" button), but this step can be done later ("Continue" button), for tables requiring logging (for a backup). For more information, refer to chapter Primary key manager.

• Temporary unicode dialog

If you open your application in 4D v17 64-bit, and your starting application is not in unicode, 4D will offer to temporarily switch your base to unicode.

Since unicode improves speed, this step should have been done since several versions. If this is not the case, do so quickly. For more information, refer to the Compatibility page chapter.

Use the Maintenance and Security Center (MSC) again to check and repair the structure and data.

As a reminder, on the structure:

• orphan methods (__Orphan__xxxxx) are indicated by warnings in the MSC log file and can be deleted using the Explorer (after checking that their code is no longer useful);

• detection of duplicate object names on forms are no longer allowed: they are reported to you as warnings in the MSC log file. Just ask for a repair of the database so that the names are changed (In this case, pay attention to programming on object names).

• detection of obsolete Images (PICT format). Verifying the application in the MSC chapter.
  See paragraph Pictures in PICT format in the Deprecated or deleted features manual. These warnings can affect static images as well as images stored in the image library or in form objects.
  
  Note: to convert these images: see Conversion of picture type.

• Undesirable characters in names  (".", "[", and "]")
  As of 4D v16 R4, the use of periods (.) And / or square brackets ([ ]) is deprecated in the following elements:
  
  • variable names
  • table names
  • field names
  • project method names
  
  To help developers bring their applications into compliance with this rule, the Verifying the application action automatically looks for the presence of these unwanted characters in the names of variables, tables, fields, and methods. If these characters are detected, "anomalies" are reported by the MSC and the log file contains the appropriate warnings:
  
  
  
  In this case, it is strongly recommended to rename these elements in your application.

Data information:

• detection of duplicates in unique fields:
  
  Additional information is provided: When using the MSC or a command like VERIFY DATA FILE, the generated log files now contain the names of the tables and fields involved, as well as each duplicate value.
  Note : When entering data, the "Duplicate Key" error dialog now contains the names of the concerned table and field, as well as the duplicate value, and the command GET LAST ERROR STACK also contains detailed information about possible duplicates.
  When 4D opens a data file, if it is necessary to build (or rebuild) an index, duplicates are now automatically detected in the associated declared field (s). In this case, a specific alert dialog box is displayed before opening the database, providing the user with the information necessary to identify and remove duplicates:
  
  

Converting from v16 to v17 does not require rebuilding the database indexes (with the exception of a Japanese version of 4D).

But if the update is from an older version (especially if updating the Unicode library - ICU - International Components for Unicode - is necessary), all text and keyword indexes in 4D can be rebuilt. This is done automatically when the database is first opened (warning: this operation may take a significant amount of time).

Note: As of 4D v16, we have significantly optimized the global reindexing algorithm for the database data. All of its processes were reviewed and this operation can now be up to twice as fast. Global reindexing is required, for example, after repairing the database or when the .4dindx file has been deleted.

It is possible to open a database in version 16 Rx with a version 4D v16.x and vice versa. However, code using the new features will not work and should be disabled. But a database converted to v17 can no longer be opened in 4D v16.

Note: Similarly, a v17 Rx database can also be reopened with a 4D version v17.x.