Warsztat 2: Transakcje na formularzu ciągłym.

TransOnForm.zip
Autor: Krzysztof Pozorek
Baza w formacie MsAccess 2000
27kB, 09-03-2003

TransHS.zip
Autor: Hubert Szczerba
Baza w formacie MsAccess 2000
26kB, 12-03-2003

Opis problemu:

Transakcje w Accessie są, ale programiści z Microsoftu jakby zatrzymali się z połowie drogi... i zaimplementowali transakcyjność dość nieśmiało. W efekcie transakcje można stosować na poziomie kodu procedur, ale nie pozwalają one objąć swoim działaniem najprostszych zmian dokonanych z poziomu interfejsu użytkownika.

Wydaje się to sporym zaniedbaniem i jest dużym ograniczeniem, bo nie pozwala na wycofanie zmian wprowadzanych w najbardziej naturalny dla Accessa sposób, czyli poprzez formularz.

Problem jest niebagatelny, czego przykładem są różne próby rozwiązania tej kwestii. Najbardziej klasyczne wydają się dwa podejścia do tematu:
1. Używamy formularzy niezwiązanych i zapisujemy zmiany do (niewidocznej) zmiennej typu recordset. 
2. Używamy formularzy opartych na tabelach tymczasowych, a następnie dane przepisujemy (lub nie) do właściwej bazy.
Czyli tzw. łapanie lewą ręką za prawe ucho...

Czy nie ma sposobu, aby zmusić jednak Accessa do transakcji na formularzach bez tych wszystkich zabiegów? Ideałem byłoby, gdyby dane można było modyfikować nie tylko na formularzu pojedynczym, ale także ciągłym i również w widoku Arkusz danych. Czy to możliwe?

Rozwiązanie:

No oczywiście! Przecież jesteście na stronie o sztuczkach i chwytach... A to miejsce (wystarczy spojrzeć na stronę główną), gdzie takie rozwiązania po prostu wyciąga się z magicznego kapelusza i gotowe.

Co ja będę gadał, i tak pewnie nie doczytaliście do tego miejsca, tylko ściągnęliście już przykładowy program, zamieszczony u góry.

Jednak chce powiedzieć tylko, że przykład korzysta z nowej właściwości formularzy w Accessie 2000, która pozwala oprzeć źródło danych nie tylko na tabeli i kwerendzie, ale również na recordsecie! To chyba wyjaśnia zasadę działania programu, dostępną jednak dopiero w Accessie 2000.

W Accessie 97 mamy mniejsze możliwości, jednak i te pozwoliły zbudować analogiczny mechanizm Stanley'owi P już jakiś czas temu. Oto jego rozwiązanie, które było moim 'natchnieniem'.

Krzysztof Pozorek

P. S. Dzięki dla Krzysztofa Naworyty za uzupełnienia do programu.

---

Otrzymałem jeszcze jeden przykład (TransHS.zip), wykorzystujący opisaną wyżej zasadę budowania transakcji na formularzu. Autorem programu jest Hubert Szczerba, oto co pisze Hubert:

Twój formularz w przykładzie TransOnForm.zip działa super, jeżeli tylko mogę coś zasugerować, to tworzenie oddzielnego workspace dla każdego formularza - bez tego szybko się zacznie program wykrzaczać. Przesyłam też moje rozwiązanie, które zwykle używam.

Dziękuje za tę uwagę, jednak co do tworzenia oddzielnego workspace, to zrezygnowałem z tego rozmyślnie.
Rozwiązanie Huberta działa OK, jeśli Admin nie ma hasła. Jednak jeśli Admin założy hasło, to wywołanie:

Set wspF2 = DBEngine.CreateWorkspace("F2", "admin", "")
'zakładamy. że Admin nie ma hasła
wspF2.BeginTrans

spowoduje błąd (niewłaściwa nazwa konta lub hasło).

Metoda użyta w programie TransOnForm.zip, odwołująca się bezpośrednio do DBEngine:

DBEngine.BeginTrans

działa bez względu na zabezpieczenie bazy hasłem użytkownika. Przydatność obu sposobów zakładania transakcji, zależeć może od konkretnej realizacji.