Compatibility page

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: 2003.x, 2004.x, v11 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.
• Automatic Transactions during Data Entry: Automatically starts a multi-transaction when an input form is first opened when the form has a subform. This option is intended only for 4D First users. It should not be used for 4D applications, where it is preferable that the transactions be handled by the developer.
• Use 4DVAR Comments instead of Brackets: This option sets the notation to use when inserting 4D expressions on static pages. When the option is checked (default value), the syntax you need to use is the standard HTML notation (<!--4DVAR MAVAR-->).
  When the box is not checked, the syntax you need to use is the notation with square brackets ([MAVAR]) — which is a proprietary solution used in former versions of the 4D Web server.
• 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. In Unicode mode, the database engine, the language and the menus handle Unicode character strings natively. In non-Unicode mode (also called ASCII compatibility mode), the ASCII character set is used.
  This option allows the compatibility of converted databases to be maintained. It is checked by default for databases created with 4D v11 and higher, and unchecked in converted databases.
  Notes:
  
  • This option is specific to each database. You can therefore have a Unicode database coexist with non-Unicode components (or vice versa) in interpreted mode.
  • You can also configure the Unicode mode using the SET DATABASE PARAMETER command.
  The specific characteristics of Unicode support in 4D are detailed in the Language Reference manual. For more information, refer to ASCII Codes.
• 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 GET LIST ITEM PARAMETER). 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 Web server mechanism allowed the value of variables posted by means of an HTTP form or a GET type URL to be copied automatically 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, variables must have been pre-declared in a COMPILER_WEB project method.
  Starting with 4D v13.4, this mechanism is obsolete and no longer available in new databases. For compatibility, it is maintained in converted databases but it can be disabled by unchecking this compatibility option. We now recommend using the dedicated commands WEB GET VARIABLES or WEB GET BODY PART.