Auto-increment et cles etrangeres sur diferents sgdb.

**jota5450** · 20/09/2006, 10h55

slt.

Apres avoir lu
http://ditch.developpez.com/dotnet/factories/#LI
et
http://nx.developpez.com/articles/dac/, je me trouve avec quelques problemes.

Comment recuperer le dernier auto-increment(cle-primaire) dune table(table_master), pour l´inserer dans une deuxieme table(table_detail), mais que le code soit independant de la sgdb?

j´ai penser a faire une table "Auto-inc", ou ce serait moi a controler les indices. par exemple "id_auto,id_doc"...

je lirais le max(id_auto), en fonction du doc, je recupere la valeur dans une variable du prog,
je commence une transaction ou j´update la id_auto de "auto_inc", et j´insere la ligne dans table _master, et les lignes detail dans table_detail, bien entendu avec id_auto=id_auto+1. finalment je termine la transaction.

Comme vous le pouvez voir, si y a 2 lectures de id_auto au meme temps, vive les problemes...

Quelqu´un a des idees de comment pouvoir faire cela, de maniere independantes des sgdb?

**mymyma** · 20/09/2006, 11h51

Si j'ai bien compris, tu veux faire un insert dans un table, récupérer l'id de l'insert que tu viens juste de faire et l'ajouter dans une autre table (en tant que clé étrangère).

Pour cela, tu peux faire :

Code :

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

1
2
3
4
 
insert into table_master values (...);
insert into table detail (id_table_master, ....) 
values ((select max(id) from table_master), ....);

Ce sont des requetes SQL vraiment simple qui ne devraient pas dépendre du SGDB.

**titoumimi** · 20/09/2006, 11h54

le problème du select max(id), c'est si il y a un autre enregistrement quasi simultané, ça risque de corrompre l'intégrité des données non ?

**mymyma** · 20/09/2006, 11h55

Bien possible

**SQLpro** · 20/09/2006, 16h06

La norme SQL:2003 à définit les deux méthodes d'uato incrémentation :
SEQUENCE (Oracle par exemple)
IDENTITY (SQL Server par exemple);

Pourt récupérer le dernier jeton :
SEQUENCE.NEXTVAL pour le séquenceur
@@IDENTITY ou IDENT_CURRENT dans la IDENTITY.

A +

Xo · 21/09/2006, 13h26

Un petit lapsus, Frédéric, je crois que vous vouliez dire :

SEQUENCE.CURVAL

à la place de :

SEQUENCE.NEXTVAL

**SQLpro** · 21/09/2006, 16h40

oooooooops !

A +

**jota5450** · 22/09/2006, 11h35

slt.

Merci bien pour les reponses.

J´ai mis du temps a repondre parce que je faissais des tests.

Dans mon code, je devrais tester quelle sgdb est utiliser, ce que je n´avais pas trop envie

, mais bon....

Juste petite derniere question: vous connaissez d´autres situations, ou le code sql va dependre directement de la sgdb?

merci

Xo · 22/09/2006, 23h11

Envoyé par jota5450

Juste petite derniere question: vous connaissez d´autres situations, ou le code sql va dependre directement de la sgdb?

Oui.

En fait, le SQL est un langage normé, mais diversement implémenté par les différents moteurs SGBD.

Par exemple, si tu lis l'article de SQLPro sur les jointures, tu as à la fin un résumé indiquant quel type de jointure est supporté par quel SGBD. L'exemple le plus frappant étant le support tardif du mot-clé JOIN par Oracle, implémenté en version 9.

SI tu jettes un oeil au thread Création de la FAQ SQL, cherche le sujet proposant de limiter le nombre de lignes retournés par une requêtes, il y a au moins 3 solution entre TOP, LIMIT, ROWNUM ...

Je ne parles pas de l'usage des fonctions, les tableaux de l'article suivants (Toutes les fonctions de SQL) te donneront une idée de leur diversité

J'arrête là, je ne voudrais pas passer mon WE sur ce post

La conclusion, c'est que pour contruire un Data Access Layer, tu dois absoluement avoir l'information du SGBD en cours (et sa version) afin de pouvoir gérer ses spécificités.

**jota5450** · 26/09/2006, 10h30

slt.

merci xo, pour toutes tes reponses.
on a changer d´idee. on donne le choix que entre 2 sgdb.

**SQLpro** · 26/09/2006, 10h56

Le seul moyen de tenter une compatibilité voisine de 100% est de procéder UNIQUEMENT par procédures stockées.

En effet j'ai démontré que même un simple SELECT * FROM table ORDER BY 1 ne donnait pas les mêmes résultats sur les divers SGBDR du marché.

A lire : http://sqlpro.developpez.com/cours/s...age=partie1#L4

A +