Transactions

Salut,

Je ne sais pas si le post est vraiment terminé? Pas de Commit ni
Rollback?

Je n'ai pas testé mais sachant que la transaction s'effectue sur une
connexion, ma démarche serait d'ouvrir une autre connexion et de lire les
enregistrements à partir de la connexion ouverte en transactionnel pour les
rechercher dans les enregistrements de l'autre connexion. Ceux qui ne sont
pas retrouvé doivent répondre au problème!?

Comme je disais plus haut, je n'ai pas testé mais le sujet m'interesse.
Du coup je me documenterai un peu et si j'ai plus d'infos, j'alimente ce
fil. De ton coté, si tu pouvais remonter des résultats sur le groupe ce
serait bien!

A+

Rv

"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de
news:1194617042.225936.165070@q5g2000prf.googlegroups.com...
Bonjour,
Je cherche à enregistrer dans deux tables liées (FactureEnTete et
FactureDetail) des enregistrements en ayant la certitude que les
modifications soient effectuées dans les deux tables. Pour cela
j'utilise les transactions avec un BeginTrans, CommitTrans et Rollback
si besoins est.
Voici mon problème,
A l'intérieur de cette transaction (après le BeginTrans et avant le
CommitTrans), je veux pouvoir rechercher dans mes tables (ou
ailleurs !!) les données préalablement validées par un Update mais pas
encore enregistrées par le CommitTrans (car toujours dans le cache !).
Ex : Importation de la facturation d'une base de données externe vers
ma base de données actuelle
1- Création de ma requête de sélection des données de facturation
2- Pour chaque enregistrement de cette requête, je boucle :
3- Je démarre ma transaction (BEGINTRANS)
4- Je recherche si dans ma base de données actuelle le code
client existe dans ma table CLIENTS
5- S'i n'existe pas je le créé
6- S'il existe
j'enregistre les données dans ma table de facture entete de ma base de
données actuelle

Oups Effectivement j'ai du appuyer par inadvertence sur envoyer avant
de finir mon post ... désolé !

Effectivement RV CommitTrans et Rollback sont de rigueur !

Le soucis est de retrouver des enregistrement "transactionnel" qui ne
sont pas, du coup, affichés dans les tables mais en cache car le
committrans n'as pas encore eu lieu. (je travail en DAO)
J'ai bien pensé a faire des transactions imbriquées mais selon ma
config ce n'est pas possible (source de données ODBC) !
Par contre l'utilisation de plusieurs sessions de travail serait peut
etre une bonne idée ?
Je vais tester ça !

PS : pour finir mon post précedent : pour chaque ligne de facture
(détail) que je veux enregistrer, je verifie avant si le code client
de la ligne existe dans ma table CLIENTS via un DBLOOKUP. s'il
n'existe pas je le créé : et c'est là le probleme : lors de la
création de ce client l'opération se trouve encore dans la transaction
et donc le client n'est pas physiquement dans ma table CLIENTS !. Une
fois le client créé (dans le cache donc) j'enregistre ensuite ma ligne
qui elle aussi se trouvera donc dans le cache (normal c'est ce que je
veux)! Lorsque que je passe à la ligne suivante (boucle) je verifie si
le code client de cette nouvelle ligne existe via, toujours, mon
DBLOOKUP sur ma table CLIENTS. Hors s'il existe, puisque créé
precedemment mais dans le cache, il ne le trouve pas !! Et donc tente
de le créer une seconde fois !! Et là paf, DOUBLON !

Merci RV pour ta réponse et pour celles des autres qui voudraient
bien m'aider !

Bonjour,

En deux temps, tu crée d'abord tes clients qui n'existent pas et ensuite
tu réalise tes transactions.


"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de news:1194623802.272693.201660@o3g2000hsb.googlegroups.com...
Oups Effectivement j'ai du appuyer par inadvertence sur envoyer avant
de finir mon post ... désolé !

Effectivement RV CommitTrans et Rollback sont de rigueur !

Le soucis est de retrouver des enregistrement "transactionnel" qui ne
sont pas, du coup, affichés dans les tables mais en cache car le
committrans n'as pas encore eu lieu. (je travail en DAO)
J'ai bien pensé a faire des transactions imbriquées mais selon ma
config ce n'est pas possible (source de données ODBC) !
Par contre l'utilisation de plusieurs sessions de travail serait peut
etre une bonne idée ?
Je vais tester ça !

PS : pour finir mon post précedent : pour chaque ligne de facture
(détail) que je veux enregistrer, je verifie avant si le code client
de la ligne existe dans ma table CLIENTS via un DBLOOKUP. s'il
n'existe pas je le créé : et c'est là le probleme : lors de la
création de ce client l'opération se trouve encore dans la transaction
et donc le client n'est pas physiquement dans ma table CLIENTS !. Une
fois le client créé (dans le cache donc) j'enregistre ensuite ma ligne
qui elle aussi se trouvera donc dans le cache (normal c'est ce que je
veux)! Lorsque que je passe à la ligne suivante (boucle) je verifie si
le code client de cette nouvelle ligne existe via, toujours, mon
DBLOOKUP sur ma table CLIENTS. Hors s'il existe, puisque créé
precedemment mais dans le cache, il ne le trouve pas !! Et donc tente
de le créer une seconde fois !! Et là paf, DOUBLON !

Merci RV pour ta réponse et pour celles des autres qui voudraient
bien m'aider !

Tu vois je n'avais pas bien compris la demande! Tu ne trouve pas le client
éventuellement créé car justement tu fais un dblookup qui par défaut va
travailler sur une autre connexion que ta transaction. Donc soit on trouve
le moyen de faire le dblookup explicitement sur la connexion
transactionnelle, soit on utilise d'autres méthodes de recherche de dao
(find, findfisrt je ne sais plus! ou seek ou directement une requête SQL
avec le bon where ou ...), soit on utilise la solution de Michel_D qui
contourne le problème technique. Si elle convient c'est encore le plus
simple!
Désolé je n'ai pas tout en tête. Surtout sur DAO que j'utilise de moins en
moins! Tiens nous au courant.

A+

Rv


"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de
news:1194623802.272693.201660@o3g2000hsb.googlegroups.com...
Oups Effectivement j'ai du appuyer par inadvertence sur envoyer avant
de finir mon post ... désolé !

Effectivement RV CommitTrans et Rollback sont de rigueur !

Le soucis est de retrouver des enregistrement "transactionnel" qui ne
sont pas, du coup, affichés dans les tables mais en cache car le
committrans n'as pas encore eu lieu. (je travail en DAO)
J'ai bien pensé a faire des transactions imbriquées mais selon ma
config ce n'est pas possible (source de données ODBC) !
Par contre l'utilisation de plusieurs sessions de travail serait peut
etre une bonne idée ?
Je vais tester ça !

PS : pour finir mon post précedent : pour chaque ligne de facture
(détail) que je veux enregistrer, je verifie avant si le code client
de la ligne existe dans ma table CLIENTS via un DBLOOKUP. s'il
n'existe pas je le créé : et c'est là le probleme : lors de la
création de ce client l'opération se trouve encore dans la transaction
et donc le client n'est pas physiquement dans ma table CLIENTS !. Une
fois le client créé (dans le cache donc) j'enregistre ensuite ma ligne
qui elle aussi se trouvera donc dans le cache (normal c'est ce que je
veux)! Lorsque que je passe à la ligne suivante (boucle) je verifie si
le code client de cette nouvelle ligne existe via, toujours, mon
DBLOOKUP sur ma table CLIENTS. Hors s'il existe, puisque créé
precedemment mais dans le cache, il ne le trouve pas !! Et donc tente
de le créer une seconde fois !! Et là paf, DOUBLON !

Merci RV pour ta réponse et pour celles des autres qui voudraient
bien m'aider !

Bonjour,
Merci de vos réponses,
effectivement j'ai également pensé que le plus simple serait de
travailler en deux temps : recherche et création éventuelle de mon
client et ensuite dans ma transaction inserer mes factures entete et
détail...je ne vois pas d'autres solutions. Je vais quand meme essayer
la methode FindFirst au cas où cette fonction rechercherait également
dans le cache ce que j'en doute (mais je ne suis pas expert en la
matiere :)
Merci Michel_D. Merci Rv
Je vous tiens au courant

Cordialement

Et bien mea coulpa !

je viens de tester la methode FindFirst et effectivement ca marche !!
Le fait est, comme le disait RV, que le dblookup doit rechercher via
une autre connexion que celle utilisée pour mon enregistrement CLIENT
(currentDb) et l'aide ACCESS dit ceci sur cette fonction : "Les
modifications non sauvegardées dans des enregistrements de domaine ne
sont pas prises en compte par cette fonction". Par contre le FindFirst
lui trouve bien l'enregistrement malgré qu'il ne soit pas présent
"physiquement" dans la table !!
Merci pour tout !

Cordialement

Bonjour,

Dans tout les cas il faut faire la mise à jour des clients de manière
séparé par rapport aux transactions sur les factures, ensuite tu peux
agir soit de manière asynchrone comme je te l'ai indiqué ou soit
comme tu voulais faire à savoir de manière synchrone mais dans
ce cas il faut le faire dans un recordset à part (ne faisant pas partie
de tes transactions), opter pour l'un ou l'autre dépend en fait de la
charge occasionné par tes traitements (test de la présence du
client répétitif en autre).


"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de news:1194878707.478817.157910@22g2000hsm.googlegroups.com...
Bonjour,
Merci de vos réponses,
effectivement j'ai également pensé que le plus simple serait de
travailler en deux temps : recherche et création éventuelle de mon
client et ensuite dans ma transaction inserer mes factures entete et
détail...je ne vois pas d'autres solutions. Je vais quand meme essayer
la methode FindFirst au cas où cette fonction rechercherait également
dans le cache ce que j'en doute (mais je ne suis pas expert en la
matiere :)
Merci Michel_D. Merci Rv
Je vous tiens au courant

Cordialement

Salut,

J'ai fait le test suivant qui fonctionne bien. C.a.d que
l'enregistrement créé dans la transaction est bien retrouvé alors que la
transaction n'est pas encore validé :


Sub test()
Dim objWk As DAO.Workspace
Dim objRs As DAO.Recordset

Set objWk = Workspaces(0)
objWk.BeginTrans

Set objRs = CurrentDb.OpenRecordset("SELECT * FROM CLIENT")

objRs.AddNew
objRs(1) = "Testtrans4"
objRs.Update

Call objRs.FindFirst("NomClient='Testtrans4'")
MsgBox objRs.NoMatch

objRs.Close
objWk.CommitTrans

End Sub


A+

Rv

"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de
news:1194878707.478817.157910@22g2000hsm.googlegroups.com...
Bonjour,
Merci de vos réponses,
effectivement j'ai également pensé que le plus simple serait de
travailler en deux temps : recherche et création éventuelle de mon
client et ensuite dans ma transaction inserer mes factures entete et
détail...je ne vois pas d'autres solutions. Je vais quand meme essayer
la methode FindFirst au cas où cette fonction rechercherait également
dans le cache ce que j'en doute (mais je ne suis pas expert en la
matiere :)
Merci Michel_D. Merci Rv
Je vous tiens au courant

Cordialement

Salut,

J'ai posté mon test trop tard puisque tu as déjà le résultat. Ceci dit
juste un petit rectificatif car par habitude de ADO je parlais de
transaction sur une connexion alors que dans ADO la transaction s'effectue
sur un objet WorkSpace notion qui est plus large que la connexion puisque
qu'elle englobe une collection de connexions.

A+

Rv

"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de
news:1194879611.027204.13930@o38g2000hse.googlegroups.com...
Et bien mea coulpa !

je viens de tester la methode FindFirst et effectivement ca marche !!
Le fait est, comme le disait RV, que le dblookup doit rechercher via
une autre connexion que celle utilisée pour mon enregistrement CLIENT
(currentDb) et l'aide ACCESS dit ceci sur cette fonction : "Les
modifications non sauvegardées dans des enregistrements de domaine ne
sont pas prises en compte par cette fonction". Par contre le FindFirst
lui trouve bien l'enregistrement malgré qu'il ne soit pas présent
"physiquement" dans la table !!
Merci pour tout !

Cordialement

Excuses il faut lire :

alors que dans DAO la transaction s'effectue sur un objet WorkSpace

A+

Rv


"Rv" <a@b.fr> a écrit dans le message de
news:F692CD59-760E-4AF5-975C-540F0C3FC70A@microsoft.com...

Salut,

J'ai posté mon test trop tard puisque tu as déjà le résultat. Ceci dit
juste un petit rectificatif car par habitude de ADO je parlais de
transaction sur une connexion alors que dans ADO la transaction s'effectue
sur un objet WorkSpace notion qui est plus large que la connexion puisque
qu'elle englobe une collection de connexions.

A+

Rv

"Jérôme" <jeromedelestre@wanadoo.fr> a écrit dans le message de
news:1194879611.027204.13930@o38g2000hse.googlegroups.com...
Et bien mea coulpa !

je viens de tester la methode FindFirst et effectivement ca marche !!
Le fait est, comme le disait RV, que le dblookup doit rechercher via
une autre connexion que celle utilisée pour mon enregistrement CLIENT
(currentDb) et l'aide ACCESS dit ceci sur cette fonction : "Les
modifications non sauvegardées dans des enregistrements de domaine ne
sont pas prises en compte par cette fonction". Par contre le FindFirst
lui trouve bien l'enregistrement malgré qu'il ne soit pas présent
"physiquement" dans la table !!
Merci pour tout !

Cordialement