Page SQL

Cette page permet de configurer les paramètres de publication par défaut et les accès du serveur SQL intégré de 4D ainsi que des options de fonctionnement du moteur SQL de 4D. Pour plus d’informations sur le SQL dans 4D, reportez-vous à la section MissingRef dans le manuel de Référence SQL.

Il est possible de configurer les paramètres de publication par défaut du serveur SQL intégré de 4D. Ces paramètres sont accessibles dans la page SQL des Propriétés de la base. 

• L’option Lancer le serveur SQL au démarrage permet de démarrer le serveur SQL au démarrage de l’application
• Port TCP : Par défaut, le serveur SQL de 4D répond aux requêtes sur le port TCP 19812. Si ce port est déjà utilisé par un autre service ou si vos paramètres de connexion requièrent une autre configuration, vous pouvez changer le port TCP utilisé par le serveur SQL de 4D.

  Note : Si vous passez 0, 4D utilisera le numéro de port TCP par défaut, c'est-à-dire 19812.

• Adresse IP : Vous pouvez définir l’adresse IP de la machine sur laquelle le serveur SQL doit traiter les requêtes SQL. Par défaut, le serveur répond sur toutes les adresses IP (option Toutes).
  La liste déroulante “Adresse IP” liste automatiquement toutes les adresses IP présentes sur la machine. Lorsque vous sélectionnez une adresse particulière, le serveur ne répond qu’aux requêtes dirigées sur cette adresse. Cette fonctionnalité est destinée aux applications 4D hébergées sur des machines ayant plusieurs adresses TCP/IP.

  Note : Côté client, l’adresse IP et le port TCP du serveur SQL auquel l’application se connecte doivent être correctement configurées dans la définition de la source de données ODBC.

• Activer SSL : Cette option indique si le serveur SQL doit activer le protocole SSL pour traiter les connexions SQL. A noter que lorsque ce protocole est activé, le mot-clé ":ssl" devra être ajouté à l'adresse IP du serveur SQL lorsque vous ouvrirez une connexion via la commande SQL LOGIN.
  Par défaut, le serveur SQL utilise des fichiers internes pour la clé et certificat SSL. Vous pouvez toutefois utiliser des éléments personnalisés : pour cela, il vous suffit de recopier vos propres fichiers key.pem et cert.pem à l’emplacement suivant : MaBase/Preferences/SQL (où "MaBase" représente le dossier/package de la base).

• Autoriser les requêtes Flash Player : Cette option permet d’activer le mécanisme de prise en charge des requêtes Flash Player par le serveur SQL de 4D. Ce mécanisme est basé sur la présence d’un fichier, nommé "socketpolicy.xml", dans le dossier de préférences de la base (Preferences/SQL/Flash/). Ce fichier est requis par Flash Player afin d’autoriser les connexions cross-domains ou les connexions par sockets des applications Flex (Web 2.0).
  Dans la version précédente de 4D, ce fichier devait être ajouté manuellement. Désormais, lorsque vous cochez cette option, les requêtes Flash Player sont acceptées et un fichier "socketpolicy.xml" générique est créé si nécessaire pour la base.
  Lorsque vous désélectionnez cette option, le fichier "socketpolicy.xml" est désactivé (renommé). Les requêtes Flash Player ultérieures reçues par le serveur SQL sont alors rejetées.
  A l’ouverture de la base, l’option est cochée ou non en fonction de la présence d’un fichier "socketpolicy.xml" actif dans le dossier de préférences.

  Note : Il est possible de définir l'encodage utilisé par le serveur SQL pour le traitement des requêtes externes à l'aide de la commande 4D SQL FIXER OPTION.

Pour des raisons de sécurité, il est possible de contrôler les actions que les requêtes externes adressées au serveur SQL peuvent effectuer dans la base de données 4D. Ce contrôle est effectué à deux niveaux :

• au niveau du type d’action autorisé,
• au niveau de l’utilisateur ayant effectué la requête.
  Ces paramétrages peuvent être effectués via la page SQL des Propriétés de la base.

Note : Vous pouvez également utiliser la Méthode base Sur authentification SQL afin de contrôler de manière personnalisée les requêtes externes au moteur SQL de 4D.

Les paramétrages définis dans cette boîte de dialogue s'appliquent au schéma par défaut. En effet, le contrôle des accès externes à la base est basé sur le concept des schémas SQL (cf. section Implémentations du moteur SQL de 4D). Si vous ne créez pas de schémas personnalisés, le schéma par défaut inclut toutes les tables de la base. Si vous créez d'autres schémas dotés de droits spécifiques et leur associez des tables, le schéma par défaut inclut uniquement les tables non incluses dans les schémas personnalisés.

Vous pouvez configurer séparément trois types d’accès au schéma par défaut via le serveur SQL :

• Lecture seulement (données) : libre accès en lecture à toutes les données des tables de la base mais ne permet pas l’ajout, la modification ou la suppression d’enregistrements ni la modification de la structure de la base.
• Lecture/écriture (données) : accès en lecture et en écriture (ajout, modification et suppression) à toutes les données des tables de la base mais ne permet pas la modification de la structure de la base.
• Complet (données et structure) : accès en lecture et en écriture (ajout, modification et suppression) à toutes les données des tables de la base et à la structure de la base (tables, champs, liens, etc).

Vous pouvez désigner un ensemble d’utilisateurs pour chaque type d’accès. Pour cela, vous disposez de trois types d’options :

• <Personne> : si vous sélectionnez cette option, le type d’accès sera refusé pour toutes les requêtes, quelle que soit leur provenance. Ce paramètre peut être utilisé même si le système de gestion des accès via des mots de passe de 4D n’est pas activé.
• <Tout le monde> : si vous sélectionnez cette option, le type d’accès sera accepté pour toutes les requêtes (aucun contrôle n’est effectué).
• groupe d’utilisateurs : cette option permet de désigner un groupe d’utilisateurs comme seul autorisé à effectuer le type d’accès associé. Cette option requiert que la gestion des mots de passe de 4D ait été activée. L’utilisateur à l’origine des requêtes fournit son nom et son mot de passe lors de la connexion au serveur SQL.

ATTENTION : Chaque type d'accès est défini indépendamment des autres. En particulier, si vous affectez un groupe uniquement au type d'accès Lecture seulement, cela n'aura aucun effet car le groupe ainsi que tous les autres continueront de bénéficier de l'accès Lecture/écriture (affecté à <Tout le monde> par défaut). Pour définir un accès Lecture seulement, il est nécessaire de configurer l'accès Lecture/écriture.

ATTENTION : Ce mécanisme s’appuie sur les mots de passe de 4D. Pour que le contrôle d’accès au serveur SQL soit effectif, le système de mots de passe de 4D doit être actif (un mot de passe doit avoir été attribué au Super_Utilisateur).

Note : Une option de sécurité supplémentaire peut être définie au niveau de chaque méthode projet 4D. Pour plus d’informations sur ce point, reportez-vous au paragraphe “Option “Disponible via SQL”” dans la section Implémentations du moteur SQL de 4D.

• Transactions Auto-commit : cette option permet d’activer le mécanisme d’auto-commit dans le moteur SQL. Le mode auto-commit a pour but de préserver l’intégrité référentielle des données. Lorsque cette option est cochée, toute requête SELECT, INSERT, UPDATE et DELETE (SIUD) effectuée en-dehors d’une transaction est automatiquement incluse dans une transaction ad hoc. Ce principe garantit que les requêtes seront entièrement exécutées ou, en cas d’erreur, intégralement annulées.
  Les requêtes incluses dans une transaction (gestion personnalisée de l’intégrité référentielle) ne sont pas affectées par cette option.
  Lorsque cette option n’est pas cochée, aucune transaction automatique n’est générée (à l’exception des requêtes SELECT... FOR UPDATE, reportez-vous à la description de la commande SELECT). Par défaut, cette option n’est pas cochée.
  Vous pouvez également gérer cette option par programmation à l’aide de la commande FIXER PARAMETRE BASE.

Note : Seules les bases locales interrogées par le moteur SQL de 4D sont affectées par ce paramètre. Dans le cas de connexions externes à d'autres bases SQL, le mécanisme d’auto-commit est pris en charge par les moteurs SQL distants.

• Tenir compte de la casse des caractères pour les comparaisons de chaînes : cette option permet de modifier le mode de prise en compte de la casse des caractères dans les requêtes SQL. Elle est cochée par défaut, ce qui signifie que le moteur SQL établit une différence entre les majuscules et les minuscules lors des comparaisons de chaînes (tris et recherches). Par exemple “ABC”=“ABC” mais “ABC” # “Abc”.
  Dans certains cas, par exemple pour aligner le fonctionnement du moteur SQL sur celui du moteur 4D, vous pourrez souhaiter que les comparaisons de chaînes ne tiennent pas compte de la casse (“ABC”=“Abc”). Pour cela, il suffit de désélectionner l’option.
  Vous pouvez également gérer cette option par programmation à l’aide de la commande FIXER PARAMETRE BASE.