Principles for conversion

• You must have an "interpreted" version of the database (xxxx.4DB file for the structure, xxxx.4DD file for the data, as well as the Designer password to perform a conversion;

• The oldest database version that you can convert directly with 4D v18 is a 4D v11 application. If your application is older, you must use an intermediary version (between v11 and v17, with data and structure verification/repair), then convert to v18. See "Conversion" documents for older versions.

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

• Make a copy of your database before conversion;

• QuickTime is no longer supported.  
  • To convert pictures in deprecated format (PICT), you must be in v17 32-bit and 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 information, for compatibility, in an old 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 17 of 4D or 4D Server (as well as ones from v11 to v16) are compatible with 4D version 18 (structure and data files). You can convert any interpreted structure file. To do this, just launch 4D v18 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 v18 and can not be opened in a previous version.

• Converting the data file (.4DD)

For data from v11 to v14, a second dialog appears:

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

The data does not need to be converted for 4D v15, 4D v16, or 4D v17 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 (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). See 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 GET LAST ERROR STACK command 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 information necessary to identify and remove duplicates:
  
  

In consequence of the Unicode Library upgrade (ICU version 63.1 in 4D v17 R5), database conversion from v17 to v18 requires rebuilding the database indexes for text and keyword indexes.  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 always possible to open a database in version X Rx with a version 4D vX.x and vice versa (for example, a database in version 17 Rx can be opened by a v17.x). Code using the new features will simply not work and should be disabled. 

However, a database converted to vX can no longer be opened in 4D vX-1. For example, a database converted to v18 cannot be reopened with a 4D version v17.x.