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.
• Use legacy network layer: Starting with release v15, 4D applications propose a new network layer, named ServerNet, to handle communications between 4D Server and remote 4D machines (clients). The former network layer has become obsolete, but it is kept to ensure compatibility with existing databases. Using this option, you can enable or disable the former network layer at any time in your 4D Server applications depending on your needs, for example, when migrating your client applications (see the Network and Client-Server options section). ServerNet is used automatically for new databases and databases converted from a v15 release or later.
  Note that in case of a modification, you need to restart the application for the change to be taken into account. Any client applications that were logged must also be restarted to be able to connect with the new network layer (the minimum client version for using the ServerNet layer is 4D v14 R4, see the Network and Client-Server options section).
  Note: This option can also be managed by programming using the SET DATABASE PARAMETER command.
• 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.
  
• 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 continue 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.