Y a-t-il un moyen de dire, en utilisant uniquement l'objet Adodb.Connection, qu'il soit actuellement impliqué dans une transaction?
J'adorerais pouvoir tester cela sur l'objet Connect lui-même, sans compter sur la maintenance d'un booléen à côté d'elle à jour.
4 Réponses :
On dirait que vous pouvez vérifier l'état ADO. http://msdn.microsoft.com/ EN-US / Bibliothèque / MS675068% 28V = VS.85% 29.aspx
Vous connaissez probablement déjà cette autre partie mais je le posterai de toute façon.
Ceci explique comment les transactions fonctionnent avec ADO dans VB. http://support.microsoft.com/kb/198024
Je ne pense pas que tu puisses. C'était le premier endroit où j'ai regardé et on dirait que les valeurs de l'état n'ont rien à dire sur la transaction ou non. Voir: msdn.microsoft.com/fr- US / Bibliothèque / MS675546% 28V = VS.85% 29.aspx
Vous ne pouvez pas sauf si vous le suivez vous-même. L'objet de connexion n'a pas de propriété traitant de l'état de transaction. Vous devrez avoir votre procédez un drapeau dans une autre zone de table / paramètres si vous devez l'avoir (qui peut être problématique si des erreurs non définies se produisent et que le drapeau de l'état est devenu «bloqué» avec un statut non valide, vous avez besoin de venir avec un "délai d'attente" valide ou une substitution pour ignorer / tuer / écraser le précédent).
La méthode forte> Begntrans forte> peut être utilisée comme fonction qui renvoie le niveau de nidification de la transaction. Si vous créez une propriété pour stocker ceci, vous pouvez le vérifier où que vous deviez voir si elle est supérieure à 0. Lorsque vous vous engagez ou vous devrez décrémenter la propriété vous-même.
Public Function IsConnectionInsideTransaction(ByVal vADOConnection as ADOBD.Connection) As Boolean
Dim intLevel As Integer
If vADOConnection.State = AdStateOpen Then
intLevel = vADOConnection.BeginTrans()
IsConnectionInsideTransaction = (intLevel > 1)
vADOConnection.RollbackTrans
End If
End Function
J'ai pensé à des variations de la première méthode, essentiellement enveloppant l'adodb.Connection dans une nouvelle classe MyConnection qui ajouterait cette fonctionnalité et d'autres. Voulait minimiser les modifications du code existant si la pensée est possible. La deuxième manière répond à ma question, je suppose, mais me semble très risquée pour moi, je ne veux pas vraiment interagir avec la base de données à chaque fois que je vérifie ... merci pour les suggestions!
L'emballage avec votre propre classe de connexion pourrait avoir d'autres avantages. Si vous avez besoin de passer à VB.NET, cela pourrait être plus facile si vous avez enveloppé tous les objets ADO de vos propres objets. Vous pouvez les faire avoir des signatures similaires à l'ADO (pour minimiser les modifications apportées au code existant), mais n'exposez que le minimum de fonctionnalités, pour limiter la portée de l'effort de mise à niveau. Je suggérerais de les mettre dans un projet DLL afin que le projet principal ne fait même pas référence à l'ADO. Divulgation complète: nous ne l'avons pas complètement fait dans nos propres projets, mais je souhaite que nous ayons eu.
Si seulement notre moteur de rapport a utilisé un wrapper autour de adodb.connection ! J'ai joué avec l'idée de minimiser les modifications apportées au code d'extraction de rapports existant afin que les utilisateurs puissent exécuter des rapports sur une connexion sans fil (dans notre cas via un serveur RPC personnalisé).
Si vous vous connectez à un serveur Microsoft SQL et que vous pouvez compter dessus pour réagir suffisamment rapidement (c'est-à-dire que ce n'est pas de l'autre côté de la planète), vous pouvez effectuer la requête:
SELECT @@TRANCOUNT
J'aime cette réponse! DIM RSTC, SET TC RSTC = ADOCON.EXECTE ("SELECT @@ TRANCOUNT") TC = CLNG (RSTC.Fields (0))