Czy istnieje sposób, aby powiedzieć, używając tylko obiektu ADODB.Connection, czy jest on obecnie zaangażowany w transakcję?Połączenie VB6 ADO - Jak sprawdzić, czy w transakcji?
Chciałbym móc przetestować to na samym obiekcie connect, bez polegania na aktualizowaniu wartości binarnej.
Metodę, która zwraca poziom zagnieżdżenia transakcji, można użyć metody BeginTrans. Jeśli utworzysz właściwość do przechowywania tego, możesz sprawdzić ją tam, gdzie chcesz, aby sprawdzić, czy jest większa niż 0. Po zatwierdzeniu lub wycofaniu będziesz musiał zmniejszyć własność.
Private m_TransLevel As Long
Public Property Get TransactionLevel() As Long
TransactionLevel = m_TransLevel
End Property
Public Property Let TransactionLevel(vLevel As Long)
m_TransLevel = vLevel
End Property
Public Sub SaveMyData()
TransactionLevel = adoConnection.BeginTrans()
...
End Sub
Można również dostosować wartość powrotu do pracy wewnątrz funkcji, która zwraca Prawda/Fałsz, jeśli poziom> 1. Nie podoba mi się to, jak dobrze, ale to będzie wyglądać mniej więcej tak (bez obsługi błędów)
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
Wygląda na to, że możesz sprawdzić stan ADO. http://msdn.microsoft.com/en-us/library/ms675068%28v=VS.85%29.aspx
Prawdopodobnie znasz już tę drugą część, ale mimo to opublikuję.
To wyjaśnia, w jaki sposób transakcje działają z ADO w VB. http://support.microsoft.com/kb/198024
Nie sądzę, że ty mogą. To było pierwsze miejsce, na które patrzyłem i wygląda na to, że wartości państwowe nie mają nic do powiedzenia na temat transakcji. Zobacz: http://msdn.microsoft.com/en-us/library/ms675546%28v=VS.85%29.aspx –
Nie możesz, chyba że sam go śledzisz. Obiekt połączenia nie ma właściwości zajmującej się stanem transakcji. Będziesz musiał ustawić swój proces jako flagę w innej tabeli/obszarze ustawień, jeśli MUSISZ go mieć (co może być problematyczne, jeśli wystąpią nieobsługiwane błędy, a flaga stanu zostanie "zablokowana" z nieprawidłowym stanem, musisz wymyślić z poprawnym "timeout" lub przesłonięcie, aby zignorować/zabić/zastąpić poprzednie).
Jeśli łączysz się z serwerem Microsoft SQL i można liczyć na to reagować wystarczająco szybko (czyli nie jest po drugiej stronie planety) można wykonać zapytanie:
SELECT @@TRANCOUNT
Podoba mi się ta odpowiedź! dim rstc, tc zestaw rstc = adoCon.Execute ("SELECT @@ TRANCOUNT") tc = CLng (rstc.Fields (0)) –
Myślałem o odmianach pierwszej metody, zasadniczo opakowując ADODB.Connection w nowy Klasa MyConnection, która dodaje tę i inną funkcjonalność. Chciałem zminimalizować zmiany w istniejącym kodzie, jeśli to tylko możliwe. Druga metoda odpowiada na moje pytanie, jak sądzę, ale wydaje mi się bardzo ryzykowna, nie chcę wchodzić w interakcję z bazą danych za każdym razem, gdy sprawdzam ... Dzięki za sugestie! –
Zawijanie z własną klasą połączenia może mieć inne zalety. Jeśli kiedykolwiek będziesz musiał dokonać aktualizacji do VB.net, może być łatwiej, jeśli owinąłeś wszystkie obiekty ADO w swoje własne obiekty. Możesz sprawić, że będą miały podobne podpisy do ADO (w celu zminimalizowania zmian w istniejącym kodzie), ale tylko ujawnią minimalną funkcjonalność, aby ograniczyć zakres wysiłku aktualizacji. Sugerowałbym umieszczenie ich w projekcie DLL, więc główny projekt nie odwołuje się do ADO. Pełne ujawnienie: nie zrobiliśmy tego całkowicie w naszych własnych projektach, ale żałuję, że nie. – MarkJ
Jeśli tylko nasz silnik raportowania używał opakowania wokół 'ADODB.Connection'! Pomyślałem o tym, aby zminimalizować zmiany w istniejącym kodzie wyodrębniania raportu, aby użytkownicy mogli uruchamiać raporty przez połączenie bezprzewodowe (które w naszym przypadku przechodzi przez niestandardowy serwer RPC). –