La page Compatibilité regroupe les paramètres relatifs au maintien de la compatibilité avec les versions précédentes de 4D. A noter que le nombre d’options affichées dépend de la version de 4D avec laquelle la base de données a été créée à l’origine (2004.x, v11, v12...) ainsi que des paramétrages modifiés dans cette base.

Note : Cette page n'apparaît pas pour les bases de données créées avec une version courante de 4D (bases non converties).

• Les champs sont saisissables dans les dialogues : dans les versions précédentes de 4D, il n’était pas possible de saisir des valeurs par l’intermédiaire de champs dans des boîtes de dialogue (affichées par exemple à l’aide de la commande DIALOGUE). Cette limitation a été supprimée depuis 4D 2004. Vous pouvez toutefois souhaiter conserver le fonctionnement précédent, notamment si votre base de données utilise des champs dans des boîtes de dialogue pour afficher des données. Par défaut, cette option est cochée pour les anciennes bases de données converties en version 2004 et non cochée pour les bases de données créées à partir de la version 2004. 
• Boutons radio groupés par nom : dans les versions précédentes de 4D, le fonctionnement coordonné d’un groupe de boutons radio était obtenu en donnant une première lettre identique aux variables associées aux boutons (par exemple m_bouton1, m_bouton2, m_bouton3, etc.). Ce principe a été remplacé depuis 4D 2004 par le suivant : pour fonctionner de manière coordonnée, un ensemble de boutons radio doit simplement être groupé dans l’éditeur de formulaires. Pour plus d’informations sur ce point, reportez-vous à la section Boutons radio et boutons radio image.
  Ce nouveau mode est valide pour les boutons radio, les boutons radio 3D et les boutons radio image. Pour des raisons de compatibilité, l’ancien mode est conservé par défaut dans les bases de données converties. Vous pouvez cependant forcer l’utilisation du nouveau mode en désélectionnant cette option. Les bases de données créées à compter de la version 2004 utilisent le nouveau mode. 
• Recharger le formulaire pour chaque enregistrement durant un IMPRIMER SELECTION : dans les versions précédentes de 4D, le formulaire utilisé lors d’une impression lancée à l’aide de la commande IMPRIMER SELECTION était rechargé pour chaque enregistrement. Ce principe permettait de réinitialiser automatiquement tous les paramètres des objets que le développeur avait pu modifier par le langage dans l’événement formulaire Sur impression corps.
  Afin d’optimiser les performances, ce mécanisme a été supprimé à compter de 4D 2004. Le développeur 4D doit désormais réinitialiser lui-même les paramètres qu’il souhaite dans la méthode formulaire — ce fonctionnement est identique à celui des formulaires listes avec l’événement Sur affichage corps. Vous pouvez toutefois conserver l’ancien mécanisme à l’aide de cette option. Les bases de données créées à compter de la version 2004 utilisent le nouveau mode.
• Ne pas utiliser nouveau référencement des contextes : lorsque cette option n'est pas cochée (valeur par défaut), le serveur Web 4D place le numéro de contexte dans l’URL de base des documents HTML envoyés.
  Avec l’ancien système (option sélectionnée), le serveur Web 4D envoie au navigateur le numéro du contexte pour chaque élément d’une page, ce qui ralentit les traitements. Cette option peut cependant être cochée pour des raisons de compatibilité. Notez qu’après l’avoir modifiée, vous devez redémarrer la base afin que le nouveau fonctionnement soit effectif.
• Supprimer le “/” sur les URLs inconnus : dans les anciennes versions de 4D, les URLs inconnus (URLs ne correspondant à aucune page ni URLs spéciaux) étaient retournés dans les méthodes bases Sur authentification Web et Sur connexion Web ($1) sans débuter par le caractère “/”. Cette particularité a été supprimée depuis 4D 2004. Toutefois, si vous aviez mis en place des mécanismes basés sur ce fonctionnement et souhaitez le conserver, vous pouvez désélectionner cette option.
• Interdire de glisser des données ne provenant pas de 4D : à compter de la v11, 4D permet le glisser-déposer de sélections, d’objets ou de fichiers provenant de l’extérieur de 4D, comme par exemple des fichiers image, en mode Application.
  Cette possibilité doit être prise en charge par le code de la base. Dans les bases de données converties depuis une version précédente de 4D, ce principe peut entraîner des dysfonctionnements si le code existant n’est pas adapté.
  Cette option permet d’anticiper ces éventuels dysfonctionnements. Lorsqu’elle est cochée, le déposer d’objets externes est refusé dans les formulaires 4D. A noter toutefois que l’insertion d’objets externes reste possible dans les objets disposant de l’option Déposer automatique, lorsque l’application peut interpréter automatiquement les données déposées (texte ou image). Pour plus d’informations, reportez-vous à la section Glisser Déposer.
• Exécuter CHERCHER PAR FORMULE sur le serveur et Exécuter TRIER PAR FORMULE sur le serveur : à compter de 4D v11, pour des raisons d’optimisation, les commandes de recherches et de tris “par formule” sont exécutées sur le serveur ; seul le résultat est retourné au poste client distant. Il s’agit des commandes CHERCHER PAR FORMULE, CHERCHER PAR FORMULE DANS SELECTION et TRIER PAR FORMULE. En cas d’appel direct de variables dans la formule, la requête est calculée avec la valeur de la variable sur le poste client. Par exemple,
   CHERCHER PAR FORMULE([latable];[latable]lechamp=lavariable)
  sera exécuté sur le serveur mais avec le contenu de la variable lavariable du client. En revanche, ce principe n’est pas appliqué pour les formules utilisant des méthodes qui, elles-mêmes, font appel à des variables : dans ce cas la valeur des variables est évaluée sur le serveur.
  Dans les bases de données converties, ce fonctionnement peut affecter les algorithmes existants. Par conséquent, par défaut dans ce contexte ces commandes continuent d’être exécutées sur le poste client. Si vous souhaitez bénéficier du nouvel algorithme dans une base convertie, il vous suffit de cocher ces options.
  Note : Cette option peut être définie par process via la commande FIXER PARAMETRE BASE.
• CHERCHER PAR FORMULE utilise jointures SQL : à compter de 4D v11, les commandes CHERCHER PAR FORMULE et CHERCHER PAR FORMULE DANS SELECTION effectuent des “jointures” à la manière du SQL. Avec ce principe, il n’est pas nécessaire qu’un lien automatique structurel existe entre la table A et la table B pour pouvoir utiliser une formule contenant [Table_A ]champ_X=[Table_B ]champ_Y.
  Ce mécanisme pouvant générer des dysfonctionnements dans les applications existantes, il est désactivé par défaut dans les bases de données converties. Il est conseillé de l’activer (après contrôle du code de la base) en cochant cette option afin de bénéficier de l’optimisation des commandes de recherche par formule.
  Notes :
  
  • Lorsque le mode “jointure SQL” est activé, les commandes CHERCHER PAR FORMULE et CHERCHER PAR FORMULE DANS SELECTION utilisent toutefois les liens automatiques définis dans l’éditeur de structure dans les cas suivants :
    - si la formule ne peut se pas décomposer en éléments de la forme {champ ;comparateur ;valeur}
    - si deux champs de la même table sont comparés.
  • Cette option peut également être définie par process via la commande FIXER PARAMETRE BASE.
• Autoriser les transactions imbriquées : active la prise en charge des transactions multi-niveaux. A compter de la v11, 4D accepte les transactions imbriquées sur un nombre de niveaux illimité. Ce fonctionnement pouvant générer des dysfonctionnements dans les bases développées avec des versions précédentes de 4D, il est désactivé par défaut dans les bases converties (les transactions restent limitées à un seul niveau). Pour en bénéficier dans une base convertie, vous devez cocher cette option. Cette option n’est pas cochée par défaut. Elle est spécifique à chaque base de données.    
  Note : Cette option n’a pas d’effet sur les transactions effectuées dans le moteur SQL de 4D. Les transactions SQL sont toujours multi-niveaux. 
• Mode Unicode : permet d’activer ou de désactiver le mode Unicode pour la base courante. Cette option doit être cochée car elle est requise pour les applications 4D en 64 bits. 
• Définir le point et la virgule comme caractères d'emplacement dans les formats numériques : à compter de la version 11, 4D utilise les paramètres système régionaux pour les formats d’affichage numériques (cf. “Formats numériques” dans la section Formats d'affichage). 4D substitue les caractères “,” et “.” dans les formats d’affichage des numériques par, respectivement, le séparateur des milliers et le séparateur décimal définis dans le système d’exploitation. Le point et la virgule sont alors considérés comme des caractères d’emplacement, à l’instar du 0 ou du #. Dans les versions précédentes de 4D, les formats d’affichage des numériques ne tenaient pas compte des paramètres régionaux du système. Par exemple, le format “###,##0.00” est un format valide pour un système américain. Toutefois, lorsqu’il est appliqué à une valeur numérique affichée sur un système français ou suisse, le résultat est incorrect.
  Dans les bases de données converties, par souci de compatibilité, le nouveau mécanisme n’est pas actif. Pour en bénéficier, vous devez cocher cette option.
• Affectation automatique des variables : dans les versions précédentes de 4D, un mécanisme standard du serveur Web permettait de recopier automatiquement dans des variables process 4D la valeur des variables postées via un formulaire HTTP ou un URL de type GET. En mode interprété, la valeur de toute variable reçue était directement copiée dans une variable process 4D du même nom ; en mode compilé, les variables devaient être pré-déclarées dans une méthode projet COMPILER_WEB.
  A compter de 4D v13.4, ce mécanisme est obsolète et n'est plus disponible dans les nouvelles bases de données. Par compatibilité, il est maintenu dans les bases de données converties mais il est alors possible de le désactiver en désélectionnant cette option de compatibilité. Il est désormais recommandé d'utiliser les commandes dédiées WEB LIRE VARIABLES ou WEB LIRE PARTIE CORPS.
• Enregistrer les méthodes en Unicode : Cette option est ignorée (les méthodes sont toujours enregistrées en Unicode). Pour plus d'informations, veuillez consulter les versions antérieures de la documentation. 
• Utiliser le type date au lieu du format date ISO dans les objets : vous permet de stocker les dates dans les attributs d'objets avec le type date plutôt qu'en texte au format ISO. Dans les versions précédentes de 4D, les dates dans les attributs d'objets pouvaient uniquement être stockées sous forme de chaîne de caractères. A compter de 4D v16 R6, les dates dans les attributs d'objets peuvent être stockées avec le type date. Vous pouvez activer ce fonctionnement en cochant cette option (les dates précédemment stockées au format texte ISO ne seront pas modifiées, mais les nouvelles dates seront stockées avec le type date). Ce paramètre peut également être géré par programmation pour chaque process à l'aide de la commande FIXER PARAMETRE BASE et du sélecteur Dates dans les objets.
• Utiliser la nouvelle architecture pour les applications déployées : cette option est disponible pour toutes les applications à compter de 4D v15 R4. Elle permet d'activer ou de désactiver de nouveaux mécanismes liés au déploiement des applications 4D (elle doit être définie sur le poste qui génère l'application finale). Les mécanismes contrôlés par cette option sont décrits dans les paragraphes Dernier fichier de données ouvert, Gestion du fichier de données dans les applications finales et Gestion de la connexion des applications clientes. Cette option est désélectionnée par défaut dans les applications converties. Pour bénéficier des nouveaux mécanismes, il est nécessaire de la cocher explicitement.
• Utiliser la notation objet pour accéder aux propriétés des objets (nécessite Unicode) : cette option permet l'utilisation des caractères ".", "[" et "]" comme symboles de notation objet, utilisés pour accéder à des propriétés tokenisées -- et non comme partie de nom de table, champ, méthode ou variable. Activer cette option est obligatoire dans une base de données créée dans une version antérieure à 4D v17 si vous souhaitez bénéficier de la notation objet, puisque les signes ".[ ]" étaient autorisés dans les noms de ces éléments dans les versions précédentes de 4D. En activant cette option, vous déclarez que le code de votre base est en conformité avec la notation objet. Il est recommandé de vérifier cette conformité au préalable à l'aide du CSM (voir Page Vérification). Pour plus d'informations sur la notation objet, veuillez vous reporter à la section Utiliser la notation objet.
  Note : Cette option est obligatoire dans les bases de données binaires converties à partir de 4D v20.
• Utiliser XPath standard : Par défaut, cette option est décochée pour les bases converties à partir d'une version 4D antérieure à la v18 R3 et cochée pour les bases créées sous une version 4D v18 R3 ou une version plus récente. A partir de v18 R3, l'implémentation de XPath dans 4D a été modifiée pour une meilleure conformité et pour la prise en charge d'un plus grand nombre de prédicats.
  Par conséquent, les fonctionnalités non standard de l'implémentation antérieure ne fonctionnent plus. Elles incluent :
  • le caractère "/" initial n'est pas seulement le noeud racine -  l'utilisation du caractère / comme premier caractère d'une expression XPath ne déclare pas un chemin absolu à partir du noeud racine
  • pas de noeud courant implicite - le noeud courant doit être intégré dans l'expression XPath
  • pas de requêtes récursives dans les structures répétées - seul le premier élément est parsé.

Même si ces fonctionnalités ne sont pas standard, vous pouvez continuer de les utiliser afin que votre code continue de fonctionner -- dans ce cas, l'option doit simplement être décochée. Par ailleurs, si votre code ne dépend pas de l'implémentation non standard et si vous souhaitez profiter des fonctionnalités XPath avancées dans vos bases (cf. commande DOM Chercher element XML), assurez-vous que l'option Utiliser XPath standard est cochée.

• • Utiliser un LF comme caractère de fin de ligne sur macOS : À compter de 4D v19 R2, 4D écrit les fichiers texte avec un caractère LF (line feed ou "saut de ligne") comme caractère de fin de ligne par défaut au lieu de Retour Chariot dans les nouveaux projets sur macOS. Si vous souhaitez bénéficier de ce nouveau comportement dans les projets convertis à partir de versions antérieures de 4D, cochez cette option. Voir TEXTE VERS DOCUMENT et Document vers texte.
  • Ne pas ajouter de BOM lors de l'écriture d'un fichier texte unicode par défaut : À partir de 4D v19 R2, 4D écrit des fichiers texte sans BOM (Byte order mark) par défaut. Dans les versions antérieures, les fichiers texte étaient écrits avec un BOM par défaut. Sélectionnez cette option si vous souhaitez activer le nouveau comportement dans les projets convertis. Voir TEXTE VERS DOCUMENT et Document vers texte.
  • Utiliser DirectWrite pour le rendu des textes dans les formulaires : Sous Windows, les projets et bases de données 4D créés avec 4D v19 R3 et avec des versions plus récentes utilisent l'API DirectWrite dans les formulaires. Cette API améliore le rendu du texte, notamment dans les configurations à haute DPI. Cependant, elle n'est pas utilisée par défaut dans les projets et bases de données créés avec une version antérieure de 4D car elle peut modifier l'affichage global de vos formulaires existants. Cochez cette option si vous souhaitez bénéficier de cette API dans vos formulaires -à noter néanmoins qu'elle peut vous contraindre à adapter la conception de vos formulaires sous Windows. Lorsque l'option est cochée, DirectWrite sera utilisé pour le rendu du texte avec les objets formulaire tels que le texte statique et d'entrée, les cases à cocher, les boutons et les boutons radio. Notez que cette option ne modifiera pas le rendu du texte pour les listbox qui utilisent déjà DirectWrite.
  • Traduire les NULL en valeurs vides non cochée par défaut à la création d'un champ : Pour une meilleure conformité avec les spécifications ORDA, dans les bases de données créées avec 4D v19 R4 et les versions plus récentes, la propriété de champ Traduire les NULL en valeurs vides n'est pas cochée par défaut lorsque vous créez des champs. Vous pouvez appliquer ce comportement par défaut à vos bases de données converties en cochant cette option (il est désormais recommandé de travailler avec des valeurs Null car elles sont entièrement prises en charge par ORDA).