DELPHI NEWS N°6

Février 1997

compatibles, ...).
Exécutez le projet et appuyez sur le bouton "import". Vous constatez que les enregistrements contenus dans le fichier ASCII (de clé 1 à 10) sont ajoutés à la table CUSTOMER.DB puisqu'ils sont affichés par DBGrid1.
Maintenant, que se passerait-il si vous déclenchiez plusieurs fois l'import ? Allez-y !
Une exception est levée : Violation de clé.  C'est logique puisque, à présent, la table CUSTOMER.DB contient déjà les enregistrements que le TBatchMove tente de lui ajouter : il en résulte un conflit.
La gestion de ce conflit dépend des propriétés AbortOnKeyViol et KeyViolTableName du TBatchMove.
Si, pendant une opération, une violation d'intégrité se produit dans la table Destination alors que AbortOnKeyViol est à True (la valeur par défaut), Delphi interrompt immédiatement le traitement en levant une exception. Si vous préférez que l'opération se poursuive, tous les enregistrements en conflit étant alors placés dans une table des violations, basculez AbortOnKeyViol à False.
Quand AbortOnKeyViol est à False, vous devez fournir dans KeyViolTableName le nom d'une table Paradox (l'extension DB peut être omise) qui contiendra les enregistrements en conflit. Cette table est créée localement dès qu'une violation d'intégrité a lieu.
Reprenez le projet, mettez la propriété  AbortOnKeyViol du TBatchMove à False, puis entrez "KeyViol" comme nom pour la table des violations (KeyViolTableName).
Relancez le projet et appuyez plusieurs fois sur le bouton "import". Plus aucune exception ne se produit; par contre, une table KEYVIOL.DB est créée dans DBDEMOS et contient les mêmes enregistrements que ceux du fichier d'import.
Remarquez que la table ne contient qu'une fois chaque enregistrement, car elle est supprimée et recréée à chaque fois que vous appuyez sur le bouton "import".
Pour le vérifier, il suffit de supprimer les enregistrements de clé 1 à 10 dans la table CUSTOMER.DB, puis de déclencher l'import : la table KEYVIOL.DB est détruite puisqu'il n'y a plus de conflit. Par conséquent, la présence de cette table peut servir à déterminer si l'import s'est correctement déroulé.

Remarque : les enregistrements en conflit avec la table Destination sont placés dans la table des violations quand :
- ils existent déjà dans la table Destination (violation de clé);
- ils ont violé une règle d'intégrité référentielle de la table Destination;
- ils possèdent des champs qui ne respectent pas les contrôles de validité de la table Destination (champ obligatoire, fourchette de valeurs, ...).

Le bulletin des utilisateurs DELPHI

7