Promotic
WikipediaLinkedInYoutubeTwitterFacebook

PmaAdo - Szczegółowy opis obiektu

Patrz: obiekt PmaAdo, PmaAdo - Praktyczne przykłady
 
Obiekt PmaAdo zawiera jedno podłączenie do bazy danych (ADO Connection). Podłączenie do bazy danych można wykonać przy pomocy metody DbOpen. W tak podłączonej bazie danych można wtedy wykonywać:
1) Polecenia SQL, które nie zwracają danych w formie obiektu AdoRecordset: przy pomocy metody DbExecute, na przykład INSERT, UPDATE, DELETE, CREATE TABLE, itd.
2) Polecenia SQL, które zwracają dane w formie obiektu AdoRecordset: przy pomocy metody RsOpen, na przykład SELECT, itd.
 
Każdy polecenia wytwarzające obiekt AdoRecordset (RsOpen lub DbExecute) może mieć jednoznaczny identyfikator (sId), pod którym obiekt PmaAdo zapamięta sobie wynik polecenia. Przy zastosowaniu jednoznacznego identyfikatora można uzyskać istniejący obiekt AdoRecordset przy pomocy metody RsGet lub można go zamknąć przy pomocy metody RsClose. Obiekt PmaAdo może więc jednocześnie zawierać kilka rezultatów poleceń SQL w formie obiektów AdoRecordset.
 
Obiekt Wrapper:

Sposób implementacji metod i właściwości (np. AdoRecordset.Update) we wszystkich obiektach ADO (np. AdoRecordset, AdoField, AdoRecord) w przypadku błędu powoduje natychmiastowe zatrzymanie wykonywania skryptu, który wywołał daną metodę. Taki sposób pracy jest niepożądany. Z tego powodu PROMOTIC automatycznie zawija każdy obiekt ADO do własnej warstwy bezpieczeństwa (obiekt Wrapper). Wrapper umożliwia wywołanie wszystkich metod i właściwości dowolnego obiektu, który jest zawinięty przez Wrapper. Wrapper zapewnia wychwycenie ewentualnego błędu w pierwotnym obiekcie i zapamiętuje kod ostatniego błędu. Przede wszystkim zabrania zatrzymania wykonywania skryptu w przypadku błędu podczas wywołania metod obiekt ADO. Na obiekt zawinięty w warstwie bezpieczeństwa obiekt Wrapper jest najlepiej patrzeć jako na obiekt pierwotny, ponieważ warstwa udostępni wszystkie właściwości i metody obiektu pierwotnego. Dodatkowo dodaje własne właściwości przeznaczone do testowania wyniku ostatniej operacji ponad obiektem (pomyślna/niepomyślna). Jeżeli niektóra metoda lub właściwość piertownego obiektu zwraca inny obiekt, wtedy Wrapper pierwotnego obiektu wychwyci i zawinie nowo zwrócony obiekt do nowego własnego obiektu Wrapper. W ten sposób jest zapewnione, że wszystkie obiekty w hierarchii ADO są automatycznie zawijane do warstwy bezpieczeństwa.

 
Właściwości dodane przez obiekt Wrapper do metod i właściwości obiekt ADO (np. AdoRecordset, AdoField):
- Pm_LastErr - Zwraca kod liczbowe błędu ostatniego wywołania metody (właściwości) obiektu (wartość 0 oznacza wykonanie bezbłędne).
- Pm_LastTextErr - Zwraca tekstowy opis błędu ostatniego wywołania metody (właściwości) obiektu.
 
W podobny sposób można bezpośrednio w obiekcie PmaAdo odczytać wynik ostatniej operacji dla DbExecute oraz RsOpen przy pomocy właściwości LastErr oraz LastTextErr.

Odczytanie wyniku ostatniej operacji (nad obiektem PmaAdo, AdoRecordset, AdoField) jest zatem odpowiednie jeżeli nie można z góry zapewnić (ocenić) wyniku operacji i jednocześnie sama metoda nie zwraca wyniku operacji. Na przykład DbExecute, RsOpen, AdoRecordset.Update. Patrz Przykład.

 
Obiekt ADO Record:

W zależności od konkretnego ADO Provider może się wydarzyć, że jednowierszowy wynik polecenia SQL nie zostanie zwrócony w formie obiektu AdoRecordset z jednym rekordem, lecz w postaci w formie obiektu AdoRecord (przedstawia jeden wiersz). Jednak zachowanie takie nie jest typowym dla najczęściej stosowanych ADO Provider. Obiekt AdoRecord jest zwracany raczej w przypadku jawnych operacji, kiedy z istniejącego obiektu AdoRecordset jest zwracany konkretny rekord w formie obiektu AdoRecord. Obiekt AdoRecord składa się z obiektów AdoField tak samo jak obiekt AdoRecordset, jedank w odróżnieniu od niego nie wspiera metody do zmiany pozycji bieżącego rekordu (np. MoveFirst). W celu uproszczenia w dokumentacji będziem przedstawiany powszechnie zwracany obiekt AdoRecordset, chociaż w okreĺonych pojedyńczych przypadkach może zostać zwracany także obiekt AdoRecord.

 
Programowanie asynchroniczne:

Niektóre operacje wykonywane w bazie danych mogą być wykonywane także asynchronicznie.

Uwaga: Programowanie asynchroniczne często przynosi znaczącą komplikację pracy, dlatego jest zalecany raczej dostęp synchroniczny. Jeżeli zachodzi obawa, że polecenia synchroniczne mogą trwać zbyt długo lub zachodzi obawa czekania na timeout, wtedy jest lepiej wykonywanie wszystkich operacji w tredzie roboczym (Patrz PmaSequencer").

 
Więcej informacji na temat technologii ADO patrz http://msdn.microsoft.com/en-us/library/ms679836(v=VS.85).aspx, http://www.w3schools.com/asp/ado_intro.asp lub http://www.connectionstrings.com.

Historia:
Pm8.01.00: Wytworzono
© MICROSYS, spol. s r. o.Tavičská 845/21 703 00 Ostrava-Vítkovice