Réponses aux questions fréquentes sur le pilote

Pourquoi le pilote ne voit-il pas mes tables ou vues ?

Le pilote est seulement capable de synchroniser les tables qui possèdent des contraintes de clé primaire explicites. Il se sert de ces contraintes pour déterminer quels champs utiliser pour générer des associations. À ce titre, il ignore les tables sans contrainte. Si vous tentez d'effectuer une synchronisation avec des tables qui ne comportent pas de contraintes explicites, vous devrez soit ajouter ces contraintes, soit effectuer la synchronisation avec des tables intermédiaires qui contiennent les contraintes requises. Cette seconde solution est la meilleure.

Pour être visible du pilote, une vue doit contenir au moins un nom de colonne qui porte le préfixe « PK_ » (sans distinction majuscules/minuscules).

Comment synchroniser des tables situées dans plusieurs schémas ?

Il vous faudra attribuer un alias aux tables dans le schéma de ce pilote, synchroniser avec des tables intermédiaires dans le schéma du pilote et déplacer les données entre les schémas, utiliser une vue ou créer un schéma virtuel par l'intermédiaire du nouveau paramètre de pilote « Synchroniser la ou les tables ».

Pourquoi le pilote ne traite-t-il pas les enregistrements dans le journal des événements ?

Il y a plusieurs explications à ce comportement. Tout d'abord, vous devez vérifier le champ PERPETRATOR des lignes en question et vous assurer que la valeur est différente du nom d'utilisateur du pilote. Le pilote ne vérifie le champ PERPETRATOR que si le paramètre « Autoriser le retour en boucle ? » de l'objet Éditeur a la valeur « non ». Le pilote empêche le retour en boucle des événements en ignorant tous les enregistrements pour lesquels la valeur du champ PERPETRATOR est égale au nom d'utilisateur du pilote.

Vous devez également vous assurer que les champs STATUS de l'enregistrement ont la valeur 'N' (nouveau). Les enregistrements dont les champs STATUS contiennent autre chose que 'N' ne seront pas traités. En outre, veillez à valider explicitement les modifications. En effet, les modifications restent temporaires tant que vous ne les validez pas.

Le pilote peut-il gérer les comptes utilisateur de la base de données ?

Oui, il est possible de gérer les comptes de la base de données à l'aide de code SQL incorporé. Pour plus d'informations, reportez-vous à Utilisation du langage SQL dans des événements XML.

Le pilote peut-il synchroniser les données de type binaire et chaîne en grande quantité ?

Oui. Il est possible d'inscrire et de publier des données de type binaire et chaîne en grande quantité. L'acheminement de ces données via le canal Éditeur s'effectue à l'aide de types d'événements avec retour d'interrogation.

Pourquoi l'acheminement des données via le canal Éditeur est-il si lent ?

Si le journal des événements contient un grand nombre de lignes, il doit être indexé. Tous les scripts d'installation de base de données fournissent des exemples d'index. Les instructions utilisées par le pilote pour tenir à jour le journal des événements peuvent être visualisées à l'aide du niveau de trace 3. Des exemples sont également fournis dans le fichier :

tools\sql\example\STATEMENTS.sql

Les index des scripts d'installation peuvent encore être affinés pour améliorer les performances de l'acheminement des données via le canal Éditeur. Le déplacement des index dans un autre espace table ou sur un autre disque physique que le journal des événements contribue également à augmenter ces performances.

En outre, la valeur « no » doit être attribuée au paramètre du canal Éditeur « Supprimer du journal ? ».

Le pilote peut-il synchroniser plusieurs classes ?

Oui. Les noms de colonne de clé primaire, cependant, doivent être uniques dans les classes de base de données logiques. Par exemple, si class1 est assignée à table1 avec le nom de colonne de clé primaire key1 et class2 est assignée à table2 avec le nom de colonne de clé primaire key2, le nom de key1 ne peut pas être identique à key2. Cette condition peut toujours être satisfaite si des tables ou vues intermédiaires sont utilisées.

Pourquoi les colonnes de clé étrangère et de clé primaire doivent-elles porter le même nom ?

Dans chaque classe de base de données logique, les noms de colonne de clé primaire et étrangère doivent concorder. Entre classes de base de données logiques, ils doivent être différents. Ce nom commun est utilisé par le canal Éditeur pour identifier tous les enregistrements de la table de consignation des événements qui se rapportent à un objet de base de données logique unique, même si cet objet couvre plusieurs tables.

Le pilote prend-il en charge le codage SSL ?

Non. Le mode de communication du pilote avec une base de données dépend du pilote de fabricant tiers utilisé. Certains pilotes tiers prennent en charge les sockets SSL et d'autres non. Même si le codage SSL est pris en charge, il n'existe aucune méthode normalisée qui permette de l'activer entre pilotes de fabricants tiers. La solution générale à ce problème est de placer le pilote et le pilote tiers à distance. Cette installation distante permet au pilote et au pilote tiers de s'exécuter localement sur le serveur de base de données. Toutes les données qui transitent par le réseau entre le moteur et le pilote seront alors chiffrées au format SSL.

Comment assigner des attributs à valeurs multiples à des champs de base de données à valeur unique ?

Pour plus de détails sur l'assignation d'attributs à valeurs multiples à des champs de base de données à valeur unique, reportez-vous à Assignation d'attributs à valeurs multiples à des champs de base de données à valeur unique.

Pourquoi le pilote synchronise-t-il des chaînes incorrectes ?

La base de données et le pilote tiers utilisent sans doute des codages de caractères incompatibles. Pour y remédier, vous pouvez modifier le codage des caractères utilisé par votre pilote tiers.

Pour plus d'informations, reportez-vous à la page Character Encoding Values du site Web de Sun.