The Compatibility page groups together parameters related to maintaining compatibility with previous versions of 4D. Keep in mind that the number of options displayed depends on the version of 4D with which the original database was created (2004.x, v11, v12, and so on), as well as the settings modified in this database.

Note: This page does not appear in databases created with the current version of 4D (non-converted databases).

• Fields are enterable in dialog boxes: In previous versions of 4D, it was not possible to enter values using fields in dialog boxes (displayed, for example, using the DIALOG command). This limitation has been removed since 4D 2004. You can still keep the previous behavior, especially if your database uses fields in dialog boxes to display data. By default, this option is checked for previous databases converted to version 2004 and is unchecked for databases created in version 2004. 
• Radio buttons grouped by name: In previous versions of 4D, the coordinated behavior of a group of radio buttons was obtained by giving the same first letter to the variables associated with the buttons (for example, m_button1, m_button2, m_button3, etc.). Beginning with 4D 2004 this was changed as follows: to operate in a coordinated manner, a set of radio buttons must simply be grouped in the Form editor. For more information about this, refer to Radio Buttons and Picture Radio Buttons.
  This new mode is valid for radio buttons, 3D radio buttons and picture radio buttons. For compatibility reasons, the former mode is kept by default in converted databases. However, you can force the use of the new mode by deselecting this option. Databases created in version 2004 use the new mode. 
• Reload form for each record during PRINT SELECTION: In previous versions of 4D, the form used during a print using the PRINT SELECTION command was reloaded for each record. This allowed automatically reinitializing all object settings that the developer might have changed using language in the On Printing Detail form event.
  In order to optimize performance, this mechanism was deleted beginning with 4D 2004. The 4D developer must now reinitialize the desired settings in the form method himself — this is identical to how list forms work with the On Display Detail form event. Nevertheless, you can keep the former mechanism using this option. Databases created in version 2004 use the new mode.
• Do not use new context referencing mode: When this option is not selected (default value), the 4D Web server places the context number in the basic URL of the HTML documents being sent.
  With the former system (option checked), the 4D Web server sends the context number for each item of a page to the browser, which slows down processing. This option may nevertheless be checked for compatibility reasons. Keep in mind that you must restart the database after modifying this option in order for the new operation to become effective.
• Remove “/” on unknown URLs: In former versions of 4D, unknown URLs (URLs that do not correspond to an existing page nor to a 4D special URL) were returned in the On Web Authentication and On Web Connection ($1) database methods and did not begin with the “/” character. This specificity was removed in 4D 2004. However, if you implemented algorithms based on this operation and wish to keep it, you can uncheck this option.
• Prevent drop of data not coming from 4D:Starting with v11, 4D allows drag and drop of selections, objects and/or files external to 4D, like picture files for example, in the Application mode.
  This possibility must be supported by the database code. In databases converted from previous versions of 4D, this possibility may lead to malfunctioning if the existing code is not adapted accordingly.
  This option can be used to anticipate this possible malfunctioning. When it is checked, the dropping of external objects is refused in 4D forms. Note that inserting external objects is still possible in objects having the Automatic Drop option, when the application can interpret the data being dropped (text or picture). For more information, refer to Drag and Drop.
• Execute QUERY BY FORMULA On Server and Execute ORDER BY FORMULA OnServer: Starting with 4D v11, for optimization purposes, the query and order “by formula” commands are executed on the server; only the result is returned to the client machine. This concerns the following commands: QUERY BY FORMULA, QUERY SELECTION BY FORMULA and ORDER BY FORMULA. When variables are called directly in the formula, the query is calculated with the value of the variable on the client machine. For example,
   QUERY BY FORMULA([aTable];[aTable]aField=theVariable)
  will be executed on the server but with the contents of the myvariable variable of the client. On the other hand, this principle does not apply for formulas using methods that, themselves, call variables: in this case the value of the variables is evaluated on the server.
  In converted databases, this new functioning may affect existing algorithms. Consequently, by default in this context, these commands continue to be executed on the client machine. If you want to take advantage of the new algorithm in a converted database, you can simply check these options.
  Note: This option can be set using the SET DATABASE PARAMETER command.
• QUERY BY FORMULA Uses SQL Joins: Starting with 4D v11, the QUERY BY FORMULA and QUERY SELECTION BY FORMULA commands carry out joins based on the SQL joins model. This means that it is not necessary for a structural automatic relation to exist between table A and table B in order to use a formula containing [Table_A ]field_X=[Table_B ]field_Y.
  Since this mechanism could lead to malfunctioning in existing applications, it is deactivated by default in converted databases. It is recommended to activate it (after checking the code of the database) by checking this option in order to benefit from the optimization of the query by formula commands.
  Notes:
  
  • When the "SQL joins" mode is activated, the QUERY BY FORMULA and QUERY SELECTION BY FORMULA commands nevertheless use automatic relations set in the Structure editor in the following cases:
    - If the formula cannot be broken down into elements of the {field ;comparator ;value} form
    - If two fields of the same table are compared.
  • This option can also be set per process using the SET DATABASE PARAMETER command.
• Allow Nested Transactions: Enables support of multi-level transactions. Beginning with v11, 4D accepts nested transactions on an unlimited number of levels. Since this new operation can lead to malfunctioning in databases developed with former versions of 4D, it is disabled by default in converted databases (transactions remain limited to a single level). If you want to take advantage of transactions on several levels in a converted database, you must check this option.
  By default, this option is not checked. It is specific to each database.    
  Note: This option has no effect on transactions carried out in the SQL engine of 4D. SQL transactions are always multi-level. 
• Unicode mode: Used to enable or disable the Unicode mode for the current database. Must always be checked since it is required by 4D 64-bit applications.
• Use period and comma as placeholders in numeric formats: starting with v11, 4D uses regional system parameters for numeric display formats (see “Number formats” in Display formats). 4D automatically replaces the “,” and “.” characters in numeric display formats by, respectively, the thousand separator and the decimal separator defined in the operating system. The period and comma are thus considered as placeholder characters, following the example of 0 or #. In previous versions of 4D, numeric display formats do not take the regional parameters of the system into account. For example, the “###,##0.00” format is a valid format for an American system. However, when it is applied to a numeric value displayed on a French or Swiss system, the result is incorrect.
  In converted database, for the sake of compatibility, this new mechanism is not activated. To take advantage of it, you must check this option.
• Automatic variable assignment: In previous versions of 4D, a standard mechanism of the Web server automatically recopied the value of variables sent by means of an HTTP form or a GET type URL into 4D process variables. In interpreted mode, the value of any variable received was copied directly into a 4D process variable with the same name; in compiled mode, the variables must have been pre-declared in a COMPILER_WEB project method.
  Beginning with 4D v13.4, this mechanism is obsolete and no longer available in new databases. For compatibility, it is maintained in converted databases but you can disable it by unchecking this compatibility option. We now recommend using the dedicated WEB GET VARIABLES or WEB GET BODY PART commands.
• Save methods as Unicode: this option is ignored (methods are always save as Unicode). Please refer to previous versions of documentation for more information. 
• Use date type instead of ISO date format in objects: allows you to store dates in object attributes as date type rather than text in ISO format. In previous versions of 4D, dates in object attributes could only be stored as strings. Starting with 4D v16 R6, dates in object attributes can be stored in date type. You can enable this behavior by checking this option (dates previously stored in the ISO format will remain "as is", but any new dates saved will be in date type). This feature can also be managed programmatically, per process, using the SET DATABASE PARAMETER command and the Dates inside objects selector.
• Use new architecture for application deployments: This option is available for all applications starting with 4D v15 R4. It enables or disables new mechanisms related to the deployment of 4D applications (it has be to set on the machine that generates the final application). The mechanisms controlled by this option are described in the Last data file opened and Management of connections by client applications sections. This option is unchecked by default in converted applications. In order to benefit from these new mechanisms, you will need to check it explicitly. 
• Use object notation to access object properties (Unicode required): This option allows the use of ".", "[" and "]" characters in your code as object notation symbols to define token members -- and not as a part of a table, field, method, or variable name. Activating this option is mandatory for databases created in versions prior to 4D v17 if you want to use object notation, since the ".[]" symbols were allowed in names in all previous 4D releases. By activating this option for your converted database, you declare that its code is compliant with object notation. It is recommended that you check the compatibility of your code using the MSC (see Verify page). For more information on object notation, please refer to the Using object notation section. 
  Note: This option is mandatory in converted binary databases as of 4D v20.
• Use standard XPath: By default this option is unchecked for databases converted from a 4D version prior to v18 R3, and checked for databases created with 4D v18 R3 and higher. Starting with v18 R3, the XPath implementation in 4D has been modified to be more compliant and to support more predicates. As a consequence, non-standard features of the previous implementation no longer work. They include:
  • initial "/" is not the root node only - using a / as first character in a XPath expression does not declare an absolute path from the root node
  • no implicit current node - the current node has to be included in the XPath expression
  • no recursive searches in repeated structures - only the first element is parsed.

Although not standard, you might want to keep using these features so that your code continues to work as before -- in this case, just set the option unchecked. On the other hand, if your code does not rely on the non-standard implementation and if you want to benefit from the extended XPath features in your databases (as described in the DOM Find XML element command), make sure the Use standard XPath option is checked.

• Use LF for end of line on macOS: Starting with 4D v19 R2 (and 4D v19 R3 for XML files), 4D writes text files with line feed (LF) as default end of line (EOL) character instead of CR (CRLF for xml SAX) on macOS in new projects. If you want to benefit from this new behavior on projects converted from previous 4D versions, check this option. See TEXT TO DOCUMENT, Document to text, and XML SET OPTIONS.
• Don't add a BOM when writing a unicode text file by default: Starting with 4D v19 R2 (and 4D v19 R3 for XML files), 4D writes text files without a byte order mark (BOM) by default. In previous versions, text files were written with a BOM by default. Select this option if you want to enable the new behavior in converted projects. See TEXT TO DOCUMENT, Document to text, and XML SET OPTIONS.
• Use DirectWrite for text rendering in forms: On Windows, 4D projects and databases created with 4D v19 R3 and higher use the DirectWrite API in forms. This API improves text rendering especially in high DPI configurations. However, it is not used by default in projects and databases created with a previous 4D version because it can modify the overall display of your existing forms. Check this option if you want to benefit form this API in your forms -- but keep in mind that it may require that you adapt the design of your forms on Windows. When the option is checked, DirectWrite will be used for text rendering with form objects like static and input text, checkboxes, buttons and radio buttons. Note that it will not modify text rendering for listboxes which already use DirectWrite.
• Map NULL values to blank values unchecked by default a field creation: For better compliance with ORDA specifications, in databases created with 4D v19 R4 and higher the Map NULL values to blank values field property is unchecked by default when you create fields. You can apply this default behavior to your converted databases by checking this option (working with Null values is now recommended since they are fully supported by ORDA).