Les champs dits en incréments automatiques (type +) sont très pratiques pour gérer automatiquement des identifiants. Par exemple, vous souhaitez disposer d'un identifiant absolu pour vos clients. Le champ de type incrément automatique vous permet de vous décharger sur Paradox de la gestion de sa valeur (le champ sera automatiquement valorisé à l'imputation d'une nouvelle insertion).

 

Alors où est le problème?

 

1°) Si l'on vide la table, la numérotation automatique redémarre au dernier numéro créé plutôt qu'au chiffre 1. Ceci est tout à fait normal (on ne réaffecte pas les anciens numéros). Cependant cela est pénalisant s'il s'agit simplement de vider les tables avant une mise en exploitation. Pour résoudre le problème, il faut restructurer la table, remplacer l'incrément par un type Entier Long, valider la structure, restructurer à nouveau et replacer le champ de type Incrément automatique).

 

2°) Si votre table est endommagée pour une raison ou une autre (ça arrive), il arrive que l'utilitaire de reconstruction de tables (tutility) de Paradox renumérote tout simplement en partant de 1 vos champs de type incrément (les trous dus aux suppressions d'enregistrement sont comblés). Cette renumérotation quasi systématique jusqu'à la version 7 est devenue plus rare en version 8 et 9. Mais, sauf si vous êtes un fanatique de la roulettte russe, attention aux dégâts.


Les dégâts:

 

Aucun si votre champ incrémenté n'est pas utilisé dans d'autres tables. En revanche, si votre client a passé des commandes, a été destinataire de factures, et que vous avez mémorisé dans vos tables commandes et factures l'identifiant du client plutôt que toutes les informations de celui-ci, tutilty a mélangé vos identifiants client de telle sorte que les commandes et factures ont changé de destinataire ! Et tutilty le fait bien sûr en cachette ce qui fait que le jour où vous vous en rendez compte (une heure, un jour ou un mois après), votre week-end suivant est confisqué pour la remise en l'état de vos bases.

 

Que faire:

 

Oublier les champs en incrément automatique Paradox et gérer les vous-même. Evidemment, cela nécessite de programmer un peu mais vous aller y gagner en souplesse. Rien ne vous empêche par exemple de gérer un incrément à l'intérieur d'une année.

Exemple de solution:

 

La première solution, très simple est d'utiliser la fonction ObjectPal cMax pour obtenir la plus grande valeur existante dans la table. Cette solution présente cependant un certain nombre d'inconvénients (dont certains sont rédhibitoires en réseau):

 

1) le temps d'exécution de la fonction cmax est fonction de la taille de la table. Sur des tables importantes, cela peut être pénalisant,

 

2) en environnement réseau, un autre utilisateur effectuant la même opération d'insertion, peut obtenir la même valeur par cmax (1er utilisateur demande le cmax, 2nd utilisateur demande cmax, 1er utilisateur enregistre son enregistrement avec cmax+1, 2nd utilisateur va avoir un refus lors de l'enregistrement),

 

3) toujours en environnement réseau, la fonction cMax pose un verrou exclusif sur la table.Cela implique que l'opération sera bloquée si par exemple un autre utilisateur a posé un verrou sur un enregistrement de la table.

Pour éviter les points 1 et 3, on peut remplacer l'utilisation du cmax par une fonction end() sur un tcursor attaché sur la table concernée et utilisant l'index correspondant au champ incrément. Il reste cependant l'inconvénient 2.

 

Si ce risque est à éliminer il est nécessaire de gérer de façon séparée un compteur par champ de type incrément. Nous présentons dans la note technique ObjectPal programmation de l'incrément automatique une solution globale que vous pourrez enrichir et mettre en oeuvre pour traiter tous vos problèmes d'incrément.