Bonjour,
je développe une application en C# pour Pocket PC. Pour l'accès aux données
(base SQL Server CE) j'utilise ADO.Net en mode déconnecté.
Lorsque l'on souhaite encapsule des traitements d'accès aux données dans des
transactions le problème, en ADO.Net déconnecté est que les connexions sont
sans arrêt ouvertes et fermé et donc il est difficile de tout encapsuler dans
des transaction sachant que bien souvent la transaction globale doit se faire
sur la même connexion.
Ma question est la suivate :
- dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après
chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou
ouvrez-vous simplement votre connexion à l'ouverture de l'application pour la
fermer à la fermeture de l'application (apparament, à ce que j'ai lu,
Microsoft préconise la première solution mais elle n'est pas pratique lorsque
l'on veut gérer finement les transactions),
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
> Ma question est la suivate : - dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou ouvrez-vous simplement votre connexion à l'ouverture de l'application pour la fermer à la fermeture de l'application (apparament, à ce que j'ai lu, Microsoft préconise la première solution mais elle n'est pas pratique lorsque l'on veut gérer finement les transactions),
la connection est ouverte un temps infinitesimal, le temps d'envoyer quelques update, insert, delete, select, et est refermée de suite. une transaction n'est pas faite pour faire une pile d'undo utilisateur, par exemple sur une grille. on est bien d'accord ? le dataset est la pour ça. l'utilisateur charge les données en mémoire, et dispose de mécanismes qui comprend le langage "modified/unchanged".
donnez nous un exemple precis histoire qu'on le fasse ensemble en deconnecté.
> Ma question est la suivate :
- dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après
chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou
ouvrez-vous simplement votre connexion à l'ouverture de l'application pour
la
fermer à la fermeture de l'application (apparament, à ce que j'ai lu,
Microsoft préconise la première solution mais elle n'est pas pratique
lorsque
l'on veut gérer finement les transactions),
la connection est ouverte un temps infinitesimal, le temps d'envoyer
quelques update, insert, delete, select, et est refermée de suite.
une transaction n'est pas faite pour faire une pile d'undo utilisateur, par
exemple sur une grille. on est bien d'accord ?
le dataset est la pour ça. l'utilisateur charge les données en mémoire, et
dispose de mécanismes qui comprend le langage "modified/unchanged".
donnez nous un exemple precis histoire qu'on le fasse ensemble en
deconnecté.
> Ma question est la suivate : - dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou ouvrez-vous simplement votre connexion à l'ouverture de l'application pour la fermer à la fermeture de l'application (apparament, à ce que j'ai lu, Microsoft préconise la première solution mais elle n'est pas pratique lorsque l'on veut gérer finement les transactions),
la connection est ouverte un temps infinitesimal, le temps d'envoyer quelques update, insert, delete, select, et est refermée de suite. une transaction n'est pas faite pour faire une pile d'undo utilisateur, par exemple sur une grille. on est bien d'accord ? le dataset est la pour ça. l'utilisateur charge les données en mémoire, et dispose de mécanismes qui comprend le langage "modified/unchanged".
donnez nous un exemple precis histoire qu'on le fasse ensemble en deconnecté.
Stéphane ANDRE
Je suis entièrement d'accord avec votre remarque concernant les transactions. J'ai l'habitude d'utiliser les transactions avec d'autres langages (Transac-SQL, V.Foxpro), mon problème est que parfois je souhaite encapsuler des traitements importants au sein d'une même transaction (sauvegarde entête et ligne détails de factures, MAJ des stocks, MAJ des encours clients, incrémentation du dernier n° de facture). Or, certains de ces traitement sont effectués par appel à des méthodes et si malencontreusement l'une de ces méthodes ferme la connexion tout est perdu. De plus, avec les autres langages que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction effectuant des MAJ de données, une transaction et de la valider, si tout s'est bien passé, en fin de méthode. Dans les traitements appellant ces fonctions je peux également démarrer une transaction globale, celles définies aux sein des fonctions (méthodes en C#) devenant alors des transactions de sous niveau. Cela permet d'avoir un comportement très modulaire et très sécurisé. je n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à cause du mode déconnecté qui coupe fréquemment la connexion.
Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel exemple concernant une bonne implémentation des transaction avec ce modèle de données. Je pense toutefois qu'il doit y avoir une solution optimale.
Je vous remercie pour l'attention que vous portez à mon problème.
"Ambassadeur Kosh" a écrit :
> Ma question est la suivate : > - dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après > chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou > ouvrez-vous simplement votre connexion à l'ouverture de l'application pour > la > fermer à la fermeture de l'application (apparament, à ce que j'ai lu, > Microsoft préconise la première solution mais elle n'est pas pratique > lorsque > l'on veut gérer finement les transactions),
la connection est ouverte un temps infinitesimal, le temps d'envoyer quelques update, insert, delete, select, et est refermée de suite. une transaction n'est pas faite pour faire une pile d'undo utilisateur, par exemple sur une grille. on est bien d'accord ? le dataset est la pour ça. l'utilisateur charge les données en mémoire, et dispose de mécanismes qui comprend le langage "modified/unchanged".
donnez nous un exemple precis histoire qu'on le fasse ensemble en deconnecté.
Je suis entièrement d'accord avec votre remarque concernant les transactions.
J'ai l'habitude d'utiliser les transactions avec d'autres langages
(Transac-SQL, V.Foxpro), mon problème est que parfois je souhaite encapsuler
des traitements importants au sein d'une même transaction (sauvegarde entête
et ligne détails de factures, MAJ des stocks, MAJ des encours clients,
incrémentation du dernier n° de facture). Or, certains de ces traitement sont
effectués par appel à des méthodes et si malencontreusement l'une de ces
méthodes ferme la connexion tout est perdu. De plus, avec les autres langages
que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction effectuant
des MAJ de données, une transaction et de la valider, si tout s'est bien
passé, en fin de méthode. Dans les traitements appellant ces fonctions je
peux également démarrer une transaction globale, celles définies aux sein des
fonctions (méthodes en C#) devenant alors des transactions de sous niveau.
Cela permet d'avoir un comportement très modulaire et très sécurisé. je
n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à
cause du mode déconnecté qui coupe fréquemment la connexion.
Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel
exemple concernant une bonne implémentation des transaction avec ce modèle de
données. Je pense toutefois qu'il doit y avoir une solution optimale.
Je vous remercie pour l'attention que vous portez à mon problème.
"Ambassadeur Kosh" a écrit :
> Ma question est la suivate :
> - dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après
> chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou
> ouvrez-vous simplement votre connexion à l'ouverture de l'application pour
> la
> fermer à la fermeture de l'application (apparament, à ce que j'ai lu,
> Microsoft préconise la première solution mais elle n'est pas pratique
> lorsque
> l'on veut gérer finement les transactions),
la connection est ouverte un temps infinitesimal, le temps d'envoyer
quelques update, insert, delete, select, et est refermée de suite.
une transaction n'est pas faite pour faire une pile d'undo utilisateur, par
exemple sur une grille. on est bien d'accord ?
le dataset est la pour ça. l'utilisateur charge les données en mémoire, et
dispose de mécanismes qui comprend le langage "modified/unchanged".
donnez nous un exemple precis histoire qu'on le fasse ensemble en
deconnecté.
Je suis entièrement d'accord avec votre remarque concernant les transactions. J'ai l'habitude d'utiliser les transactions avec d'autres langages (Transac-SQL, V.Foxpro), mon problème est que parfois je souhaite encapsuler des traitements importants au sein d'une même transaction (sauvegarde entête et ligne détails de factures, MAJ des stocks, MAJ des encours clients, incrémentation du dernier n° de facture). Or, certains de ces traitement sont effectués par appel à des méthodes et si malencontreusement l'une de ces méthodes ferme la connexion tout est perdu. De plus, avec les autres langages que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction effectuant des MAJ de données, une transaction et de la valider, si tout s'est bien passé, en fin de méthode. Dans les traitements appellant ces fonctions je peux également démarrer une transaction globale, celles définies aux sein des fonctions (méthodes en C#) devenant alors des transactions de sous niveau. Cela permet d'avoir un comportement très modulaire et très sécurisé. je n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à cause du mode déconnecté qui coupe fréquemment la connexion.
Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel exemple concernant une bonne implémentation des transaction avec ce modèle de données. Je pense toutefois qu'il doit y avoir une solution optimale.
Je vous remercie pour l'attention que vous portez à mon problème.
"Ambassadeur Kosh" a écrit :
> Ma question est la suivate : > - dans votre code C# fermez-vous/ouvrez-vous la connexion avant et après > chaque bloc de code travaillant sur des données ADO (requêtes SQL, ...) ou > ouvrez-vous simplement votre connexion à l'ouverture de l'application pour > la > fermer à la fermeture de l'application (apparament, à ce que j'ai lu, > Microsoft préconise la première solution mais elle n'est pas pratique > lorsque > l'on veut gérer finement les transactions),
la connection est ouverte un temps infinitesimal, le temps d'envoyer quelques update, insert, delete, select, et est refermée de suite. une transaction n'est pas faite pour faire une pile d'undo utilisateur, par exemple sur une grille. on est bien d'accord ? le dataset est la pour ça. l'utilisateur charge les données en mémoire, et dispose de mécanismes qui comprend le langage "modified/unchanged".
donnez nous un exemple precis histoire qu'on le fasse ensemble en deconnecté.
Ambassadeur Kosh
> Je suis entièrement d'accord avec votre remarque concernant les transactions. J'ai l'habitude d'utiliser les transactions avec d'autres langages (Transac-SQL, V.Foxpro),
alors perdez cette habitudes le temps de jetter un oeil ici
mon problème est que parfois je souhaite encapsuler des traitements importants au sein d'une même transaction (sauvegarde entête et ligne détails de factures, MAJ des stocks, MAJ des encours clients, incrémentation du dernier n° de facture).
et c'est completement normal et souhaitable.
Or, certains de ces traitement sont effectués par appel à des méthodes et si malencontreusement l'une de ces méthodes ferme la connexion tout est perdu.
le schema : aucune de ces methodes n'ouvre ou ferme une connection. c'est toujours l'appelant qui s'occupe de ça. et le parametre à passer à chaque fois est la transaction. le schema BeginTrans , RollBack / Comit colle pile avec un try catch
De plus, avec les autres langages que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction effectuant des MAJ de données, une transaction et de la valider, si tout s'est bien passé, en fin de méthode.
ben voila.
Dans les traitements appellant ces fonctions je peux également démarrer une transaction globale, celles définies aux sein des fonctions (méthodes en C#) devenant alors des transactions de sous niveau. Cela permet d'avoir un comportement très modulaire et très sécurisé. je n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à cause du mode déconnecté qui coupe fréquemment la connexion.
qui coupe la connection ? les DataAdapter, les sqlCommand ? qui ? pour les dataAdapter, il y'a par exemple un CommandBehavior FillCommandBehavior ainsi, vous precisez si vous voulez laisser la connection en etat ou laisser le DA faire le boulot
Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel exemple concernant une bonne implémentation des transaction avec ce modèle de données. Je pense toutefois qu'il doit y avoir une solution optimale.
je vous livre la mienne, c pas parole d'évangile, juste le résultat d'une reflexion et de la comparaison de plusieurs patterns.
- ouvrez la connection - creez la transaction - affectez la à chaque objet sqlCommand impliqué dans l'affaire - faites le taf - Comit ou Rollback - restaurez les anciennes valeurs du champ Transaction pour chaque objet sqlCommand impliqué dans l'affaire - fermeture
normallement, y'a pas de soucis. le seul petit truc que j'aimerais, moi, c'est que ça soit Design Time. c'est à dire qu'il y'ait un objet transaction qu'on pose sur la feuille et qu'on l'attache aux acteurs impliqués dans la mise à jour. la, on fait un side effect, et ça craint un peu...
> Je suis entièrement d'accord avec votre remarque concernant les
transactions.
J'ai l'habitude d'utiliser les transactions avec d'autres langages
(Transac-SQL, V.Foxpro),
alors perdez cette habitudes le temps de jetter un oeil ici
mon problème est que parfois je souhaite encapsuler
des traitements importants au sein d'une même transaction (sauvegarde
entête
et ligne détails de factures, MAJ des stocks, MAJ des encours clients,
incrémentation du dernier n° de facture).
et c'est completement normal et souhaitable.
Or, certains de ces traitement sont
effectués par appel à des méthodes et si malencontreusement l'une de ces
méthodes ferme la connexion tout est perdu.
le schema : aucune de ces methodes n'ouvre ou ferme une connection.
c'est toujours l'appelant qui s'occupe de ça. et le parametre à passer à
chaque
fois est la transaction. le schema BeginTrans , RollBack / Comit colle pile
avec un try catch
De plus, avec les autres langages
que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction
effectuant
des MAJ de données, une transaction et de la valider, si tout s'est bien
passé, en fin de méthode.
ben voila.
Dans les traitements appellant ces fonctions je
peux également démarrer une transaction globale, celles définies aux sein
des
fonctions (méthodes en C#)
devenant alors des transactions de sous niveau.
Cela permet d'avoir un comportement très modulaire et très sécurisé. je
n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à
cause du mode déconnecté qui coupe fréquemment la connexion.
qui coupe la connection ? les DataAdapter, les sqlCommand ? qui ?
pour les dataAdapter, il y'a par exemple un CommandBehavior
FillCommandBehavior
ainsi, vous precisez si vous voulez laisser la connection en etat ou laisser
le DA faire le boulot
Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel
exemple concernant une bonne implémentation des transaction avec ce modèle
de
données. Je pense toutefois qu'il doit y avoir une solution optimale.
je vous livre la mienne, c pas parole d'évangile, juste le résultat d'une
reflexion et de la comparaison de plusieurs patterns.
- ouvrez la connection
- creez la transaction
- affectez la à chaque objet sqlCommand impliqué dans l'affaire
- faites le taf
- Comit ou Rollback
- restaurez les anciennes valeurs du champ Transaction pour chaque objet
sqlCommand impliqué dans l'affaire
- fermeture
normallement, y'a pas de soucis. le seul petit truc que j'aimerais, moi,
c'est que ça soit Design Time. c'est à dire qu'il y'ait un objet transaction
qu'on pose sur la feuille et qu'on l'attache aux acteurs impliqués dans la
mise à jour. la, on fait un side effect, et ça craint un peu...
> Je suis entièrement d'accord avec votre remarque concernant les transactions. J'ai l'habitude d'utiliser les transactions avec d'autres langages (Transac-SQL, V.Foxpro),
alors perdez cette habitudes le temps de jetter un oeil ici
mon problème est que parfois je souhaite encapsuler des traitements importants au sein d'une même transaction (sauvegarde entête et ligne détails de factures, MAJ des stocks, MAJ des encours clients, incrémentation du dernier n° de facture).
et c'est completement normal et souhaitable.
Or, certains de ces traitement sont effectués par appel à des méthodes et si malencontreusement l'une de ces méthodes ferme la connexion tout est perdu.
le schema : aucune de ces methodes n'ouvre ou ferme une connection. c'est toujours l'appelant qui s'occupe de ça. et le parametre à passer à chaque fois est la transaction. le schema BeginTrans , RollBack / Comit colle pile avec un try catch
De plus, avec les autres langages que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction effectuant des MAJ de données, une transaction et de la valider, si tout s'est bien passé, en fin de méthode.
ben voila.
Dans les traitements appellant ces fonctions je peux également démarrer une transaction globale, celles définies aux sein des fonctions (méthodes en C#) devenant alors des transactions de sous niveau. Cela permet d'avoir un comportement très modulaire et très sécurisé. je n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à cause du mode déconnecté qui coupe fréquemment la connexion.
qui coupe la connection ? les DataAdapter, les sqlCommand ? qui ? pour les dataAdapter, il y'a par exemple un CommandBehavior FillCommandBehavior ainsi, vous precisez si vous voulez laisser la connection en etat ou laisser le DA faire le boulot
Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel exemple concernant une bonne implémentation des transaction avec ce modèle de données. Je pense toutefois qu'il doit y avoir une solution optimale.
je vous livre la mienne, c pas parole d'évangile, juste le résultat d'une reflexion et de la comparaison de plusieurs patterns.
- ouvrez la connection - creez la transaction - affectez la à chaque objet sqlCommand impliqué dans l'affaire - faites le taf - Comit ou Rollback - restaurez les anciennes valeurs du champ Transaction pour chaque objet sqlCommand impliqué dans l'affaire - fermeture
normallement, y'a pas de soucis. le seul petit truc que j'aimerais, moi, c'est que ça soit Design Time. c'est à dire qu'il y'ait un objet transaction qu'on pose sur la feuille et qu'on l'attache aux acteurs impliqués dans la mise à jour. la, on fait un side effect, et ça craint un peu...
Stéphane ANDRE
Merci pour vos réponses.
"Ambassadeur Kosh" a écrit :
> Je suis entièrement d'accord avec votre remarque concernant les > transactions. > J'ai l'habitude d'utiliser les transactions avec d'autres langages > (Transac-SQL, V.Foxpro),
alors perdez cette habitudes le temps de jetter un oeil ici
> mon problème est que parfois je souhaite encapsuler > des traitements importants au sein d'une même transaction (sauvegarde > entête > et ligne détails de factures, MAJ des stocks, MAJ des encours clients, > incrémentation du dernier n° de facture).
et c'est completement normal et souhaitable.
> Or, certains de ces traitement sont > effectués par appel à des méthodes et si malencontreusement l'une de ces > méthodes ferme la connexion tout est perdu.
le schema : aucune de ces methodes n'ouvre ou ferme une connection. c'est toujours l'appelant qui s'occupe de ça. et le parametre à passer à chaque fois est la transaction. le schema BeginTrans , RollBack / Comit colle pile avec un try catch
> De plus, avec les autres langages > que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction > effectuant > des MAJ de données, une transaction et de la valider, si tout s'est bien > passé, en fin de méthode.
ben voila.
> Dans les traitements appellant ces fonctions je > peux également démarrer une transaction globale, celles définies aux sein > des > fonctions (méthodes en C#) > devenant alors des transactions de sous niveau. > Cela permet d'avoir un comportement très modulaire et très sécurisé. je > n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à > cause du mode déconnecté qui coupe fréquemment la connexion.
qui coupe la connection ? les DataAdapter, les sqlCommand ? qui ? pour les dataAdapter, il y'a par exemple un CommandBehavior FillCommandBehavior ainsi, vous precisez si vous voulez laisser la connection en etat ou laisser le DA faire le boulot
> Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel > exemple concernant une bonne implémentation des transaction avec ce modèle > de > données. Je pense toutefois qu'il doit y avoir une solution optimale.
je vous livre la mienne, c pas parole d'évangile, juste le résultat d'une reflexion et de la comparaison de plusieurs patterns.
- ouvrez la connection - creez la transaction - affectez la à chaque objet sqlCommand impliqué dans l'affaire - faites le taf - Comit ou Rollback - restaurez les anciennes valeurs du champ Transaction pour chaque objet sqlCommand impliqué dans l'affaire - fermeture
normallement, y'a pas de soucis. le seul petit truc que j'aimerais, moi, c'est que ça soit Design Time. c'est à dire qu'il y'ait un objet transaction qu'on pose sur la feuille et qu'on l'attache aux acteurs impliqués dans la mise à jour. la, on fait un side effect, et ça craint un peu...
Merci pour vos réponses.
"Ambassadeur Kosh" a écrit :
> Je suis entièrement d'accord avec votre remarque concernant les
> transactions.
> J'ai l'habitude d'utiliser les transactions avec d'autres langages
> (Transac-SQL, V.Foxpro),
alors perdez cette habitudes le temps de jetter un oeil ici
> mon problème est que parfois je souhaite encapsuler
> des traitements importants au sein d'une même transaction (sauvegarde
> entête
> et ligne détails de factures, MAJ des stocks, MAJ des encours clients,
> incrémentation du dernier n° de facture).
et c'est completement normal et souhaitable.
> Or, certains de ces traitement sont
> effectués par appel à des méthodes et si malencontreusement l'une de ces
> méthodes ferme la connexion tout est perdu.
le schema : aucune de ces methodes n'ouvre ou ferme une connection.
c'est toujours l'appelant qui s'occupe de ça. et le parametre à passer à
chaque
fois est la transaction. le schema BeginTrans , RollBack / Comit colle pile
avec un try catch
> De plus, avec les autres langages
> que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction
> effectuant
> des MAJ de données, une transaction et de la valider, si tout s'est bien
> passé, en fin de méthode.
ben voila.
> Dans les traitements appellant ces fonctions je
> peux également démarrer une transaction globale, celles définies aux sein
> des
> fonctions (méthodes en C#)
> devenant alors des transactions de sous niveau.
> Cela permet d'avoir un comportement très modulaire et très sécurisé. je
> n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à
> cause du mode déconnecté qui coupe fréquemment la connexion.
qui coupe la connection ? les DataAdapter, les sqlCommand ? qui ?
pour les dataAdapter, il y'a par exemple un CommandBehavior
FillCommandBehavior
ainsi, vous precisez si vous voulez laisser la connection en etat ou laisser
le DA faire le boulot
> Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel
> exemple concernant une bonne implémentation des transaction avec ce modèle
> de
> données. Je pense toutefois qu'il doit y avoir une solution optimale.
je vous livre la mienne, c pas parole d'évangile, juste le résultat d'une
reflexion et de la comparaison de plusieurs patterns.
- ouvrez la connection
- creez la transaction
- affectez la à chaque objet sqlCommand impliqué dans l'affaire
- faites le taf
- Comit ou Rollback
- restaurez les anciennes valeurs du champ Transaction pour chaque objet
sqlCommand impliqué dans l'affaire
- fermeture
normallement, y'a pas de soucis. le seul petit truc que j'aimerais, moi,
c'est que ça soit Design Time. c'est à dire qu'il y'ait un objet transaction
qu'on pose sur la feuille et qu'on l'attache aux acteurs impliqués dans la
mise à jour. la, on fait un side effect, et ça craint un peu...
> Je suis entièrement d'accord avec votre remarque concernant les > transactions. > J'ai l'habitude d'utiliser les transactions avec d'autres langages > (Transac-SQL, V.Foxpro),
alors perdez cette habitudes le temps de jetter un oeil ici
> mon problème est que parfois je souhaite encapsuler > des traitements importants au sein d'une même transaction (sauvegarde > entête > et ligne détails de factures, MAJ des stocks, MAJ des encours clients, > incrémentation du dernier n° de facture).
et c'est completement normal et souhaitable.
> Or, certains de ces traitement sont > effectués par appel à des méthodes et si malencontreusement l'une de ces > méthodes ferme la connexion tout est perdu.
le schema : aucune de ces methodes n'ouvre ou ferme une connection. c'est toujours l'appelant qui s'occupe de ça. et le parametre à passer à chaque fois est la transaction. le schema BeginTrans , RollBack / Comit colle pile avec un try catch
> De plus, avec les autres langages > que j'utilise, j'ai l'habitude de démarrer, dans chaque fonction > effectuant > des MAJ de données, une transaction et de la valider, si tout s'est bien > passé, en fin de méthode.
ben voila.
> Dans les traitements appellant ces fonctions je > peux également démarrer une transaction globale, celles définies aux sein > des > fonctions (méthodes en C#) > devenant alors des transactions de sous niveau. > Cela permet d'avoir un comportement très modulaire et très sécurisé. je > n'arrive conc malheusement pas à reproduire réellement cela en ADO.Net à > cause du mode déconnecté qui coupe fréquemment la connexion.
qui coupe la connection ? les DataAdapter, les sqlCommand ? qui ? pour les dataAdapter, il y'a par exemple un CommandBehavior FillCommandBehavior ainsi, vous precisez si vous voulez laisser la connection en etat ou laisser le DA faire le boulot
> Je me suis pas mal documenté sur ADO.net et je n'ai pas trouvé de réel > exemple concernant une bonne implémentation des transaction avec ce modèle > de > données. Je pense toutefois qu'il doit y avoir une solution optimale.
je vous livre la mienne, c pas parole d'évangile, juste le résultat d'une reflexion et de la comparaison de plusieurs patterns.
- ouvrez la connection - creez la transaction - affectez la à chaque objet sqlCommand impliqué dans l'affaire - faites le taf - Comit ou Rollback - restaurez les anciennes valeurs du champ Transaction pour chaque objet sqlCommand impliqué dans l'affaire - fermeture
normallement, y'a pas de soucis. le seul petit truc que j'aimerais, moi, c'est que ça soit Design Time. c'est à dire qu'il y'ait un objet transaction qu'on pose sur la feuille et qu'on l'attache aux acteurs impliqués dans la mise à jour. la, on fait un side effect, et ça craint un peu...
