Récupérer le dernier id créé [Résolu]

[veriecherie]

Bonjour,

Je rencontre un problème pour récupérer le dernier id créé. C'est à dire que je fais un enregistrement dans ma table et pour récupérer l'id de cet enregistrement je fais une sélection par ordre décroissant des id et je sélectionne le premier. Mon soucis et que s'il y a deux utilisateurs simultanés, l'un pourrait se retrouver avec l'enregistrement de l'autre et vice et versa.
Je voulais donc savoir si l'y avait un autre moyen plus efficace et sûr de récupérer le dernier id créé ?
J'ai une base de données access et je code en asp.

Merci

A+

[vva]

bonjour,

si tu fait une lecture du dernier ID et que tu crées immédiatement derrière le nouveau enregistrement + 1 il y a peu de chance que deux personnes le fassent en même temps mais comme nous ne pouvons jurer de rien, tu as la possibilité de générer un id automatique avec une chaîne alléatoire de lettres, chiffres et caractères où la probabilité de doublons sera quasi nulle si tu parts sur du 120 positions ou l'idéal est de bloquer ta base avant le select, de créer l'enregistrement et de libérer la base pour le prochain.

[veriecherie]

Je suis d'accord avec toi vva, la probabilité est vraiment très petite mais j'ai beau l'expliquer à mon chef il veut du sûr à 99,9%...
Donc ce que tu dis de bloquer l'accès le temps de récupérer l'id me plaît pas mal, mais je ne sais pas comment on fait cette manip, peux tu me l'expliquer stp ?

Merci

[vva]

regardes du côté des commandes COMMIT et ROLLBACK

debut de l'exemple de transaction
select * from mabase

début de transaction nommé Trans1*/
begin transaction Trans1
go
modification souhaitée
update mabase set ProductName = 'xxxxx' where ProductID = 1
go

vérification si la ligne a bien été modifié
select * from ma base

/* maintenant deux choix possible
soit je fais un commit transaction Trans1 , qui valide mon opération
soit je fais un commit rollback ,qui annule l'opération*/
soit
commit transaction Trans1
/*ou*/
Commit rollback

voilà tu peux donc faire des update,insert ... dans tous les sens et avec un simple Commit rollback tu annules tout

Nb : pour les developpeurs c'est trés utilile si vous faites plusieurs opérations SQL dans votre code à la moindre exeception un petit rollBack au serveur SQL , et hop le SGBD est nickel chrome , deplus un commit bloque la BD pour les autres clients connecté jusqu'au commit transaction ou commit rollback ,cela évite d'updater une même ligne par différents clients avant la fin d'un traitement

[veriecherie]

Merci vva pour toutes ces informations je vais chercher avec mon ami google pour avoir plus d'explications sur tous ça.

A+ et merci

[kaiser59]

Salut,

En supposant ton cas, pourquoi ne pas créer un champ heure affichant hh:mm:ss ainsi il y aurait très peu de chance pour que les deux utilisateur et exactement le meme nombre de seconde et par la même tu récupère le dernier id

[Immobilis]

Salut,

[EDIT]Pour ne pas être méchant[/EDIT]Hum Hum...

Les transactions sont faites pour replacer la base de données dans l'etat d'origine précédent les mises à jour. Pourquoi? Imaginons qu'il soit necessaire d'enregistrer des données dans plusieurs tables pour valider un achat sur un site commercial. Si une insertion echoue en cour de route il faut revenir à l'etat d'origine car plusieurs insertion précédentes peuvent avoir réussies. Ces dernières seraient incohérentes sans les données complémentaires qui n'ont pas pu être enregistrées. Il faut donc supprimer le travail effectué.

Si il s'agit d'une seule insertion c'est absolument inutile!! En cas d'echec rien ne sera fait tout simplement. Si vous voulez savoir combien d'enregistrements ont été affectés, il suffit de récupérer cette information quand elle est renvoyée par l'execution de la requete. Un "1" indique que l'enregistrement a bien été mis à jour/inséré.

Envoyé par vva

vérification si la ligne a bien été modifié

Code :

select * from ma base

Oh oui, sur une table d'un millions d'enregistrements et 200 champs. Ce sera super un "SELECT *".

Pourquoi refaire un select juste derrière?!! Ceux qui conseillent ce genre de choses devraient se poser plus de questions sur la gestion des ressources de leurs applications. En effet, dans un environnement fortement sollicité il est anti-productif voir nuisible de faire ce genre de chose. Les ressource d'un environnement applicatif ne sont pas infinies. Chaque opération inutile ajoute de la charge aux serveurs.

Envoyé par kaiser59

pourquoi ne pas créer un champ heure affichant hh:mm:ss

Pour récupérer un identifiant dans une base SQLServer, il faut utiliser

Code :

SCOPE_IDENTITY()

ou

Code :

@@IDENTITY

Rien d'autre!
Exemple:

Code :

1
2
3
4
5
6
dim rs, Auto_New_ID, SQL
SQL = "INSERT INTO MaTable (Champ1, Champs2) VALUES ('" & server.HTMLEncode(request.Form("txtChamp1")) & "', '" & server.HTMLEncode(request.Form("txtChamp1")) & "');SELECT @@IDENTITY as ID;"
Set rs = ObjConn.Execute(SQL,,1)
Set rs= rs.NextRecordset
	Auto_New_ID = rs("ID")
rs.close

Voir la methode "Execute" de l'objet Connection ici: http://www.w3schools.com/ado/met_conn_execute.asp

Pour Access

Code :

1
2
3
4
5
6
7
8
9
10
dim rs, Auto_New_ID
Set rs = server.CreateObject("ADODB.recordset")
	rs.open "MaTable", "Driver={Microsoft Access Driver (*.mdb)}; DBQ=<UNITE>:\<chemin>\nom.mdb;",1,3
		rs.AddNew
			rs("CHAMP1") = server.HTMLEncode(request.Form("txtChamp1"))
			rs("CHAMP2") = server.HTMLEncode(request.Form("txtChamp2"))
		rs.Update
		Auto_New_ID = rs("id")
	rs.close
Set rs = Nothing

[vva]

immobilis ton commentaire est très interessant et c'est bien de prendre en considération les performances des DB. Je lui ai donné une marche à suivre donc le select * doit être adapté ici en l'occurence il mettra le nom du champs de l'ID pour limiter les volumes et il n'est pas non plus obligé de le faire deux fois encore une fois c'est une indication et non un ordre strict de procéder.

pour l'ajout du champs hh.mm.ss à mon avis pas d'intérêt car le soucis ici est de s'assurer qu'au moment de l'enregistrement l'id généré sera unique ce qui est loin d'être le cas si l'on travaille avec une DB de plusieurs millions d'enreg comme l'a souligné immobilis, la possibilité de doublons ne sera pas exclus dans ce cas.

immobilis désolé mais je ne vois pas en quoi l'utilisation du SCOPE_IDENTITY()ou du @@IDENTITY assurera à notre ami la création d'un ID unique car la DB n'est pas bloquée avec cette commande et qu'un autre utilisateur peut enregistrer en même temps.

en reprennant plus en détail la demande, il est question de base access alors pourquoi ne pas déclarer le champs ID comme automatique, notre ami n'aura pas a géré la génération de l'ID et normalement access devrait éviter les doublons non ?

Veriecherie une autre méthode si le COMMIT est trop lourd tu boucles ta procédure d'insertion jusqu'autant que ton id est unique même si immobilis considère que c'est gourmand en ressources

[Immobilis]

Envoyé par vva

immobilis désolé mais je ne vois pas en quoi l'utilisation du SCOPE_IDENTITY()ou du @@IDENTITY assurera à notre ami la création d'un ID unique car la DB n'est pas bloquée avec cette commande et qu'un autre utilisateur peut enregistrer en même temps.

Plus trop le temps de détailler, mais il vaudrait mieux que tu te renseignes sur le fonctionnement de ces "fonctionnalités".

la création d'un ID unique

Est garantie par l'execution l'instruction INSERT. SCOPE_IDENTITY permet de récupérer cet identifiant de façon optimisée.



A+