Page Compatibilité

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 DIALOG). 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 PRINT 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 On Printing Detail.
  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 On Display Detail. 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 QUERY BY FORMULA, QUERY SELECTION BY FORMULA et ORDER BY FORMULA. 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,
   QUERY BY FORMULA([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 SET DATABASE PARAMETER.
• CHERCHER PAR FORMULE utilise jointures SQL : à compter de 4D v11, les commandes QUERY BY FORMULA et QUERY SELECTION BY FORMULA 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 QUERY BY FORMULA et QUERY SELECTION BY FORMULA 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 SET DATABASE PARAMETER.
• 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 GET VARIABLES ou WEB GET BODY PART.
• Utiliser l'ancienne couche réseau : à compter de 4D v15, les applications 4D proposent une nouvelle couche réseau, nommée ServerNet, chargée de gérer les communications entre 4D Server et les postes 4D distants (clients). L'ancienne couche réseau devient obsolète, mais est conservée pour assurer la compatibilité des bases existantes. A l'aide de cette option, vous pouvez activer ou désactiver à tout moment l'ancienne couche réseau dans vos applications 4D Server en fonction de vos besoins, par exemple au moment de la phase de migration des applications clientes (cf. section Options réseau et Client-serveur). ServerNet est automatiquement activé dans les nouvelles bases et les bases converties depuis les versions 15 et suivantes.
  A noter qu'en cas de modification de l'option, vous devez redémarrer le serveur pour que le changement soit pris en compte. Toute application cliente qui était connectée doit également être redémarrée afin de pouvoir se connecter avec la nouvelle couche réseau (la version minimale du client pour utiliser la couche ServerNet est 4D v14 R4, cf. section Options réseau et Client-serveur).
  Note : Cette option peut également être gérée par programmation via la commande SET DATABASE PARAMETER.
• 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 SET DATABASE PARAMETER et du sélecteur Dates inside objects.
• 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 : La notation objet requiert que la base fonctionne en mode Unicode (les options Mode Unicode et Enregistrer les méthodes en Unicode ne doivent pas être désélectionnées).