Poser une question

Re: @@identity sur bd Access avec les bons curseurs et un verrou

Salut,

Le problème ne se pose pas de la même façon avec Access. Il n'y a pas le @@identity de SQL Server. Tu dois le récupérer manuellement mais il y a un truc pour le récupérer dans la même requète sans devoir en refaire une seconde. Ce qui répond du coup à ta deuxième question sur la discussion "Re: Requete plus Interressante ?" (http://www.trucsweb.com/Forum/voirmessage.asp?forumid=10&messageid=17338&posparent=3).

Le truc est basé sur le curseur (en faite c'est une requête plus lourde puisque c'est un curseur "ouvert" mais puisqu'un ajout est beaucoup plus rare qu'un simple affichage, cette technique fonctionne très bien). Pour plus de détail voir "Cursor et LockType" (http://www.trucsweb.com/ASP/trucs.asp?no=103&type=7).

Donc en clair, tu as ton champ qui s'incrémente automatiquement, disons le champ "idAuto". Voilà donc la requête avec un "AddNew" et "Update".

' les constantes utilisées (adovbs.inc)
Const adUseServer = 2
Const adOpenKeyset = 1
Const adLockOptimistic = 3

' Connexion... et le recordset "rsAdd"
' Le secret est ici
' Spécifier les curseurs et type de verrou
rsAdd.CursorLocation = aduseserver
rsAdd.CursorType = adopenkeyset
rsAdd.LockType = adlockoptimistic
' Ouverture
rsAdd.Open RequeteSQL, ChaineDeConnnneion
if rsAdd.eof then
' C'est bien un ajout
rsAdd.AddNew
' Les ajout...
rsAdd("champ1") = "Valeur1"
rsAdd("champ2") = "Valeur2"
...
' La mise à jour AVANT la récupération du ID
rsAdd.Update
monNouveauID = rsAdd("idAuto")
rsAdd.Close
set rsAdd = nothing

Voilàs le principe. En étant dans la même connexion et avec une requête verouillé, tu évite l'ajout d'un autre enregistrement pendant la transaction. C'est moins "propre" qu'avec SQL Server comme tu dis mais c'est comme ça!

Ciao
Oznog

Réponses

Aucune réponse à ce message...