Discussion :

[jflebegue]

Bonjour,
J'ai constaté sur un tutoriel qu'interbase ne possèderait pas de type de donnée "autoincrément". Je trouve cela plutot génant qu'en est il exactement??
Je me trompe?

[Barbibulle]

Oui alors qu'ACCESS lui en a un ?? devrait on rajouté à la question...


Bon je ne dis pas que l'un est mieux que l'autre. Mais si j'avais à défendre Interbase/firebird (et beaucoup d'autres SGBD professionnels).

Un type de donnée sert à définir le type de données et non la valeur... Je ne sais pas si vous suivez. Autoincrémenté défini bien le type entier mais aussi la valeur donc pour moi ce n'est pas un type.

Sous Interbase pour faire l'équivalent d'un autoincrémenté il faut définir une colonne de type Integer (entier) et définir un générateur qui est le seul moyen d'optenir une valeur unique. Avant chaque insertion dans la table on va demander la valeur suivante au générateur et l'affecter à la colonne integer. Celà peut être fait également de manière automatique par un trigger before insert mais dans ce cas il ne faut pas que le client ait besoin de connaitre la valeur.

En règle général on combine les deux méthodes, c'est a dire on cré un trigger before update qui va définir la valeur uniquement lorsque celle ci est à null. Ce qui permet soit de définir la valeur via le trigger soit par un appel au générateur et affectation directe depuis le client.

[jflebegue]

comme dans access... ou Mysql qui lui à l'avantage de retourner l'id généré après l'INSERT.
Après une petite reflexion j'en arrive à une conclusion, est elle vérifiée??
Les BdD qui ne gèrent pas les triggers ou les proc stockées ne seraient celles qui proposent le champ autoincrement??
Les éditeurs de produits "complets" considérant que l'admin est capable de gérer ses incrémentations d'Id tout seul.
Qu'en pensez vous?

[Barbibulle]

comme dans access... ou Mysql qui lui à l'avantage de retourner l'id généré après l'INSERT.

Ah ça c'est pas bête mais hélas ne fait pas parti d'une norme.

Après une petite reflexion j'en arrive à une conclusion, est elle vérifiée??
Les BdD qui ne gèrent pas les triggers ou les proc stockées ne seraient celles qui proposent le champ autoincrement??
Les éditeurs de produits "complets" considérant que l'admin est capable de gérer ses incrémentations d'Id tout seul.
Qu'en pensez vous?

Peut être que oui.
Mais peut être que si on ne trouve pas de autoincrément c'est que tout simplement ce type n'existe pas dans les normes SQLX

Et en effet ceux qui n'ont pas de trigger/Générateur proposent une solution paliative avec les autoincrément.

Mais bon il ne faut pas non plus se focaliser sur ça, gérer à la main une clé unique avec Interbase/Firebird est très simple et l'écriture du trigger se fait entièrement automatiquement avec certain mannager de base comme IBExpert ou IBMannager ou ...

[jflebegue]

Mais peut être que si on ne trouve pas de autoincrément c'est que tout simplement ce type n'existe pas dans les normes SQLX

Et en effet ceux qui n'ont pas de trigger/Générateur proposent une solution paliative avec les autoincrément.

Mais bon il ne faut pas non plus se focaliser sur ça, gérer à la main une clé unique avec Interbase/Firebird est très simple et l'écriture du trigger se fait entièrement automatiquement avec certain mannager de base comme IBExpert ou IBMannager ou ...

Il est vrai que ce n'est pas dans la norme SQL, mais il faut avouer que cela est tout de même pratique, et ca facilite les choses, mais le revers à cela pour avoir beaucoup pratiqué access (sous la contrainte et à contre coeur) lorsque la base se scratche et que l'auto incrément repart à 1 ... 2 ... 3 ... alors que vous aviez déjà XX000 lignes cela est plutot génant (pour info dans ce genre de cas j'ai réalisé un petit script qui fait un INSERT tant qu'il y a des erreurs (et oui la primary key n'est pas unique) et j'arrete quand il n'y a plus d'erreur. Ensuite je suprime la ligne XX001. et le compteur repart pour un tour... il y aura juste un trou: l'Id XX001 mais cela n'est pas bien genant )

J'espère que vous ne m'en voudrez pas d'avoir parlé un peu longuement d'access.
Merci
Jf

[Barbibulle]

Il n'y a pas de honte à utiliser Access.

Je l'utilise moi même pour diverses raisons :
- Maintenance d'un existant.
- Maquettage rapide
- Tests divers

Et en effet le probleme des auto incrément c'est qu'on ne maitrise pas tout vus que c'est automatique. Donc le coté bien c'est que l'on a rien a faire le coté contre c'est que si ca merde on ne peut pas faire grand chose.

Vous verrez les générateurs sont très facile d'utilisation.

[jean-jacques varvenne]

en firebird l'autoincrément éxiste via un générateur, un exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
1) create generator foo;
2) create table auto_foo( champincrement integer );
 
3)CREATE TRIGGER AUTO_FOOBeforeInsert FOR AUTO_FOO
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF( New.champincrement IS NULL )THEN
  New.champincrement = GEN_ID( Foo, 1 );
END

et voilà une table avec un champ autoincrémenté...

[Darkdaemons]

hello...

ben moi j'ai chercher sur le net comment crée un champ (PRIMARY KEY) incrémental (pour IB6)...

je suis tompé sur ce tutorial qui expique bien le sujet :

http://kloo.developpez.com/interbase/IB6compteur/

mais une partie n'est pas tres conpréancive a mon gout :

Téléchargez et installez le composant IBGen qui se trouve ici

je voi pas comment l'installer ??? le fichier zip contient des fichiers ".dkp , .res , .pas " !!!

si quel qu'un la deja fais.. pourait-il m'expliquer ?
:o ou si quelqu'un sais une autre manière...

merci... ++

[Barbibulle]

C'est un composant pour Delphi, il suffit de compiler le packet et de l'installer.

Le composant ne fait que ce qui a été dit ici.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Select Gen_id(MonGenerateur,1) from rdb$database;

et renvoie la valeur incrémentée qui faut utiliser pour l'insert.