Discussion :

[zooffy]

Salut

Je cherche le moyen de récupérer le dernier enregistrement de manière certaine.
Je travaille dans une proc stock pour être tranquille, j'espère que c'est la bonne méthode pour être sûr qu'il n'y ait pas d'autre insertion en même temps.

Donc, je dois enregistrer une commande dans une table Commande et le détail de commande dans une table Détail_Commande.
L'exercice doit être classique, je pense.

Donc mon idée est d'envoyer des paramettres à une Proc Stock avec mon Client, mon premier article, sa quatité. Le reste je le récupère directement dans la base.

Je fais donc un INSERT dans ma table Commande et là, je voudrais récupérer de manière certaine l'identifiant de cette ligne (dans la table j'ai mis un compteur) pour l'insérer dans la table Détail_Commande pour la référence à la Commande.

Ma première idée est de faire un Select du plus grnad identifiant (vu que c'est un compteur en numérique) mais si quelqu'un saisi une autre commande en même temps, je n'ai pas de garantie que c'est bien mon identifiant à moi et pas celui de l'autre.

Pouvez vous m'aider ?

[Madinico]

Il y a deux possibilités à ma connaissance :

- la variable système @@IDENTITY, mais elle n'est pas souvent recommandée
- la fonction SCOPE_INDENTITY()

Tu trouveras toutes les infos dans l'aide SQL Server 2000.

[zooffy]

Merci beaucoup, ça marche du tonnerre.
Je ne connaissais pas ces variables et fonctions.

[SQLpro]

Je cherche le moyen de récupérer le dernier enregistrement de manière certaine.

Cela est impossible, une base de données enregistre les données sur le disque sans tenir compte des lignes, mais par pages, ni de l'ordre d'insertion. Vous voulez donc sans doute parrler de "ligne" de table ce qui est une notion logique et non d'enregisterement ce qui est une notion physique.

Il est impossible de récupérer la dernière ligne insérée dans une table. En effet les SGBDR reposent sur la théorie des ensembles dans laquelle il n'existe aucune notion d'ordre. Par exemple si je vous donne un sac de bille pouvez vous trouver la dernière bille que j'y ais mise ?

Sans doute es-te vous intéressé à retrouver l'id max d'un auto incrément ? Même cela ne vous garantie pas que c'est le dernier. Il est en effet possible de manipuler à la main les valeurs des auto incréments.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
CREATE TABLE T_ID
(NID   INT IDENTITY,
 DATA  VARCHAR(8));
 
INSERT INTO T_ID VALUES ('aaa');
INSERT INTO T_ID VALUES ('bbb');
INSERT INTO T_ID VALUES ('ccc');
 
SELECT * FROM T_ID;
 
NID         DATA     
----------- -------- 
1           aaa
2           bbb
3           ccc
 
SET IDENTITY_INSERT T_ID ON;
INSERT INTO T_ID (NID, DATA) VALUES (2, 'ddd');
SET IDENTITY_INSERT T_ID OFF;
 
SELECT * FROM T_ID;
 
NID         DATA     
----------- -------- 
1           aaa
2           bbb
3           ccc
2           ddd
 
DBCC CHECKIDENT ('T_ID', RESEED, -1);
 
INSERT INTO T_ID VALUES ('eee');
INSERT INTO T_ID VALUES ('fff');
 
SELECT * FROM T_ID;
 
NID         DATA     
----------- -------- 
1           aaa
2           bbb
3           ccc
2           ddd
0           eee
1           fff

Je travaille dans une proc stock pour être tranquille, j'espère que c'est la bonne méthode pour être sûr qu'il n'y ait pas d'autre insertion en même temps.

Aucunement !!! Seule une transaction avec le bon niveau d'isolation vous garantiera la chose....

Ma première idée est de faire un Select du plus grnad identifiant (vu que c'est un compteur en numérique) mais si quelqu'un saisi une autre commande en même temps, je n'ai pas de garantie que c'est bien mon identifiant à moi et pas celui de l'autre.

Vous commencez à toucher du doigt la problématique...
Lisez l'article que j'ai écrit sur l'auto incrémentation des clefs.
http://sqlpro.developpez.com/cours/clefs/

Il semble que votre formation SGBDR est très superficielle. Mon site web, comme mes bouquins peuvent vous aider à comprendre bien des choses...
Je serais curieux de savoir d'ou venez vous ? Acess ?? MySQL ??? ...

A +

[Madinico]

Je souhaite apporter des précisions à ma réponses. J'ai cru comprendre que zoofy souhaitait juste récupérer la valeur de sa clé auto incrément afin d'effectuer une insertion dans une autre table SQL.

L'utilisation des éléments que j'ai proposé peuvent être une solution si l'on reste dans la même session, ce qui est le cas dans une procédure stockée. En effet, y ajouter une gestion transactionnelle est obligatoire afin de conserver une cohérence d'informations.

J'ai bien lu ton article SQLPro, ta présentation est intéressante pour des débutants. Par contre, pourrais-tu m'expliquer pourquoi tu déconseilles d'utiliser les outils natif au SGBDR, notament sur la gestion de ces fameuses colonnes auto-incréments ?

[zooffy]

Il semble que votre formation SGBDR est très superficielle. Mon site web, comme mes bouquins peuvent vous aider à comprendre bien des choses...
Je serais curieux de savoir d'ou venez vous ? Acess ?? MySQL ??? ...

A +

Merci à tous les deux pour vos précisions.

Ma problématique est bien celle que tu décris, Madinico

Pour te répondre SQLPro, je viens du monde informatique.....
Avec 15 ans d'expérience dans le domaine, ça fait presque mal de lire "superficielle", mais rassure toi, je ne suis pas offusqué.

J'ai commencé l'informatique avec une formation centrée essentiellement sur MERISE et à l'époque on avais DBase et Paradoxe.
Puis j'ai rapidement fait des dévelopement sur ACCESS 1.0 et les versions suivantes. Puis, lorsque le web est arrivé en France, vers 1997, je m'y suis mis avec de l'ASP et su SQL Server 7.0

Donc, oui, je pense que ma connaissance de SQL Server est superficielle car je me contente de m'en servir pour acceuillir les données des sites que je programme et pas grnad chose de plus. Toutefois, j'essaie de faire en sorte d'utiliser le maximum des possibilités de SQL Server et je travaille au maximum avec les Proc Stock et les fonctions. Mais bon, ça reste léger, le gros des programme se trouvant dans les pages ASP ou ASP.NET que je peux faire. Et je dois bien avouer que mon job est beaucoup plus centré sur la programmation sur sur le SQL.
De plus, mon niveau de math étant faible (je suis autodidacte et je n'ai même pas le bac et pourtant un niveau profesionnel d'ingénieur) et donc la théorie des ensembles m'échappe pas mal. Je verrais à suivre un jour quelques cours sur le sujet, histoire d'être moins bête.

En tout cas merci pour ce coup de main et tous ceux qui suivront et pardon si mes questions sont capilotractées ou basiques.