Discussion :

[baccarios]

* Bonjour, *

L’idée est simple, je veux minimiser les accès au disque pour écrire les résultats lors d'un batch par soucis de performance.
L’idée est de faire tout le batch dans une seule transaction et faire le commit à la fin.

Ceci est fait à l'aide de l'attribut SQL_ATTR_AUTOCOMMIT de la connexion ODBC et la commande SQLEndTran à la fin.

J'ai tout mis en place et ça marche parfaitement.

Maintenant mon problème est avec la gestion des erreurs.

Si SQLExecDirect retourne SQL_ERROR, ceci n'est pas un problème car selon la doc de MSFT ceci veut dire que rien n'a été exécuté ou tout a été rolled back.

Maintenant si SQLExecDirect retourne SQL_SUCCESS_WITH_INFO ça devient plus délicat. Ceci veut dire qu'une partie ou quelques statements du batch n'ont pas été exécutés.
Je peux déterminer qu'est ce qui a été exécutée avec succès et qu'est ce qui a mal fonctionné grâce au tableau contenant les valeurs de retour de chaque statement du batch.

Mon problème est qu'est ce qui a été écrit dans la base et qu'est ce qui a été rolled back.

Ceci va dépendre étroitement de la procédure que je suis en train d’exécuter.

Si celle-ci n'a aucun mécanisme interne de gestion de transaction, alors je suis sure que je peux soit faire un commit de tout le batch (en cas de succès) soit annuler le tout. Je peux à ce moment faire un roll back, éliminer les appels causant l'erreur et relancer.

Maintenant, si la procédure géré elle même ses transactions le comportement diffère. Le premier roll back exécuté va mettre fin à la transaction globale du batch et biensure annuler tout les appels avant l'erreur.
Mais le batch continue, et tout ce qui est après l'erreur va être gérer par la procédure elle même. Même à ce niveau, je peux relancer le batch pour seulement les appels avant celui causant l'erreur.

Mon problème est comment détecter les deux cas à travers le code. Par exemple, y'a t-il un moyen pour comparer le numéro de la transaction initiale à celui de la fin du batch ou autre chose?

Merci pour votre aide

[SQLpro]

Vous faites fausse route... Faire d'un seul traitement batch une seule et même transactions est généralement une aberration totale... En effet, pendant tout ce travail toutes les tables impactées vont être verrouillées rendant impossible toute autre tentative de mise à jour. A la mise en production ce sera le meilleur moyen de bloquer tout le serveur et conduire à des verrous mortels.

Revoyez globalement votre concept. En principe les transactions doivent être les plus courtes possible et ne jamais être initiées depuis un code client.

de plus vous ne minimiserez en aucune façon les accès disque en faisant cela, bien au contraire, mais vous pourriez arriver dans une situation dangereuse ou vous satureriez à la fois la RAM et le journal de transaction.

A +