Podręcznik użytkownika

Programowanie w środowisku rozproszonym

DB2 Connect umożliwia aplikacjom dostęp do danych znajdujących się w bazach danych na serwerach DB2 System/390 i AS/400. Na przykład aplikacja uruchamiana w systemie Windows może korzystać z danych znajdujących się w bazie danych DB2 Universal Database for OS/390. Można utworzyć nowe aplikacje lub zmodyfikować istniejące, tak aby działały w środowisku hosta lub AS/400. Można również tworzyć aplikacje w jednym środowisku i przenosić je do innego.

DB2 Connect umożliwia korzystanie z następujących składników interfejsu API w produktach obsługujących bazy danych hosta, takie jak DB2 Universal Database for OS/390, pod warunkiem, że składnik ten jest obsługiwany przez produkt obsługujący bazy danych hosta:

Niektóre instrukcje SQL różnią się w zależności od konkretnego produktu opartego na relacyjnych bazach danych. Można napotkać instrukcje SQL, które są:

Instrukcje SQL dwóch pierwszych kategorii mogą być bez problemów przenoszone do innych środowisk, instrukcje trzeciej kategorii przed przeniesieniem wymagają uprzedniego wprowadzenia zmian. Generalnie instrukcji SQL języka definicji danych (DDL) nie można przenosić tak, jak instrukcji języka manipulacji danymi (DML).

DB2 Connect akceptuje pewne instrukcje SQL, które nie są obsługiwane przez produkt DB2 Universal Database. DB2 Connect przekazuje te instrukcje do serwera AS/400 lub hosta. Informacje na temat ograniczeń występujących na różnych platformach, np. ograniczenie maksymalnej długości kolumny, znajdują się w podręczniku SQL Reference.

Po dokonaniu spedycji aplikacji CICS z systemu OS/390 lub VSE do innego produktu CICS (np. CICS for AIX) może ona również korzystać z bazy danych OS/390 lub VSE przy użyciu DB2 Connect. W podręcznikach CICS/6000 Application Programming Guide i CICS Customization and Operation można znaleźć więcej szczegółów na ten temat.

Podczas programowania w środowisku hosta lub AS/400 należy uwzględnić następujące uwarunkowania:

Korzystanie z języka definicji danych (DDL)

Istnieją różnice w instrukcjach DDL między produktami IBM obsługującymi bazy danych, ponieważ pamięć w różnych systemach jest obsługiwana w różny sposób. W systemach serwera AS/400 lub hosta może być kilka etapów między projektowaniem bazy danych a wprowadzeniem instrukcji CREATE TABLE. Na przykład projekt logiczny obiektów może być tłumaczony na fizyczną reprezentację tych obiektów w pamięci przy użyciu kilku instrukcji.

Podczas prekompilacji do postaci bazy danych serwera AS/400 lub hosta prekompilator przekazuje wiele instrukcji języka DLL do serwera AS/400 lub hosta. Ta sama instrukcja może nie zostać prekompilowana dla bazy danych systemu, w którym aplikacja jest uruchamiana. Na przykład w aplikacji OS/2 instrukcja CREATE STORGROUP zostanie prekompilowana pomyślnie dla bazy danych produktu DB2 Universal Database for OS/390, a niepomyślnie dla bazy danych DB2 for OS/2.

Korzystanie z języka manipulacji danymi (DML)

Generalnie instrukcje języka DML można bez problemów przenosić do innych środowisk. Instrukcje SELECT, INSERT, UPDATE i DELETE są takie same w różnych produktach IBM obsługujących relacyjne bazy danych. Większość aplikacji używa przede wszystkim instrukcji SQL języka DML, które są obsługiwane przez program DB2 Connect.

Numeryczne typy danych

Gdy dane numeryczne są przekazywane do produktu DB2 Universal Database, mogą się zmienić typy danych. Numeryczne i nieupakowane typy dziesiętne SQLTYPE (obsługiwane przez DB2 Universal Database for AS/400) są poddawane konwersji na stałe (upakowane) dziesiętne typy SQLTYPE.

Dane mieszane

Dane mieszane składają się ze znaków z rozszerzonego zestawu znaków UNIX (EUC), ze znaków zestawu znaków dwubajtowych (DBCS) i ze znaków zestawu znaków jednobajtowych (SBCS) występujących w tej samej kolumnie. W systemach przechowujących dane w kodzie EBCDIC (OS/390, OS/400, VSE i VM) znaki SO i SI oznaczają początek i koniec danych dwubajtowych. W systemach przechowujących dane ASCII (np. w systemie OS/2 lub UNIX) znaki SI i SO nie są wymagane.

Jeśli aplikacja przekazuje dane mieszane z systemu opartego na kodzie ASCII do systemu opartego na kodzie EBCDIC, należy sprawdzić, czy jest przewidziane miejsce na znaki SO i SI. Dla każdego przejścia między danymi SBCS, a danymi DBCS do długości danych należy dodać dwa bajty. Aby uzyskać lepsze możliwości przenoszenia danych, należy użyć łańcuchów o zmiennej długości w aplikacjach wykorzystujących dane mieszane.

Długie pola

Długie pola (łańcuchy dłuższe niż 254 znaki) są obsługiwane w różny sposób w różnych systemach. Serwer hosta lub AS/400 może obsługiwać dla długich pól jedynie podzbiór funkcji skalarnych; np. DB2 Universal Database for OS/390 umożliwia jedynie użycie dla długich pół funkcji LENGTH i SUBSTR. Serwer hosta lub AS/400 może również wymagać innej obsługi dla niektórych instrukcji SQL; np. DB2 for VSE & VM wymaga, aby dla instrukcji INSERT były używane tylko zmienne języka bazowego SQLDA lub wartość NULL.

Dane typu duży obiekt (LOB)

Typ danych LOB jest obsługiwany przez DB2 Connect.

Typy zdefiniowane przez użytkownika (UDT)

Tylko odrębne typy zdefiniowane przez użytkownika są obsługiwane przez DB2 Connect. Abstrakcyjne typy danych nie są obsługiwane.

Typ danych ROWID

Typ danych ROWID jest obsługiwany przez DB2 Connect jako VARCHAR dla danych bitowych.

Typ danych 64-bitowa liczba całkowita (BIGINT)

Liczby całkowite ośmiobajtowe (64-bitowe) są obsługiwane przez DB2 Connect. Wewnętrzny typ danych BIGINT jest używany do obsługi liczności bardzo dużych baz danych dla zachowania precyzji danych.

Korzystanie z języka sterowania danymi (DCL)

Wszystkie systemy IBM zarządzające relacyjnymi bazami danych obsługują różne poziomy instrukcji GRANT i REVOKE SQL. Należy sprawdzić w publikacjach dotyczących konkretnego produktu, jakich instrukcji SQL należy użyć dla konkretnego systemu zarządzania bazami danych.

Łączenie i odłączanie

DB2 Connect obsługuje wersje CONNECT TO i CONNECT RESET instrukcji CONNECT oraz instrukcję CONNECT bez parametrów. Jeśli aplikacja wywołuje instrukcję SQL bez wcześniejszego wykonania jawnej instrukcji CONNECT TO, nawiązywane jest niejawnie połączenie z domyślnym serwerem aplikacji (jeśli taki jest zdefiniowany).

Po połączeniu się z bazą danych w polu SQLERRP obszaru komunikacyjnego SQL zwracana jest informacja identyfikująca system zarządzania relacyjną bazą danych. Jeśli serwer aplikacji jest serwerem IBM relacyjnej bazy danych, pierwsze trzy bajty pola SQLERRP zawierają jedną z następujących informacji:

DSN
DB2 Universal Database for OS/390,

ARI
DB2 for VSE & VM,

QSQ
DB2 Universal Database for AS/400,

SQL
DB2 Universal Database.

Jeśli podczas korzystania z DB2 Connect zostanie wprowadzona instrukcja CONNECT TO lub sama instrukcja CONNECT, zwrócona zostanie pusta wartość kodu kraju lub znacznika terytorium w polu SQLERRMC obszaru komunikacyjnego SQL; wartość CCSID serwera aplikacji jest zwracana w stronie kodowej lub znaczniku zbioru kodowego.

Można odłączyć się w sposób jawny, używając instrukcji CONNECT RESET (dla połączenia typu 1), instrukcji RELEASE lub COMMIT (dla połączenia typu 2) lub instrukcji DISCONNECT (dla dowolnego typu połączenia poza środowiskiem monitora TP).

Jeśli połączenie nie zostanie odłączone jawnie i aplikacja kończy się normalnie, DB2 Connect zatwierdza niejawnie dane wynikowe.
Uwaga:Aplikacja może otrzymać kody SQLCODE wskazujące na wystąpienie błędu i nadal kończyć się normalnie; w takim przypadku DB2 Connect zatwierdza dane. Jeśli dane nie powinny zostać zatwierdzone, należy podać komendę ROLLBACK.

Komenda FORCE umożliwia odłączenie wybranych lub wszystkich użytkowników od bazy danych. Jest ona dostępna dla baz danych hosta lub serwera AS/400; użytkownik może zostać odłączony od stacji roboczej DB2 Connect.

Prekompilacja

Istnieją pewne różnice w procesie prekompilacji dla różnych systemów relacyjnych baz danych. Prekompilator dla produktu DB2 Universal Database różni się od prekompilatorów dla hosta lub serwera AS/400 następującymi cechami:

Łączenie w bloki

Opcje menedżera baz danych wiązania w bloki obsługiwane przez DB2 Connect są następujące:

UNAMBIG
W skład bloków wchodzą tylko kursory jednoznaczne (wartość domyślna).

ALL
W skład bloków wchodzą kursory niejednoznaczne.

NO
Kursory nie są łączone w bloki.

Program DB2 Connect używa wielkości bloków zdefiniowanych w pliku konfiguracyjnym menedżera baz danych DB2 dla pola RQRIOBLK. Aktualne wersje DB2 Connect obsługują bloki wielkości do 32 767. Jeśli w pliku konfiguracyjnym menedżera baz danych DB2 zostaną podane większe wartości, DB2 Connect użyje wartości 32 767, ale nie zmieni wartości w pliku konfiguracyjnym menedżera baz danych DB2. Tworzenie bloków jest obsługiwane tak samo przy użyciu takich samych wielkości bloków dla dynamicznego i statycznego SQL.
Uwaga:Większość systemów opartych na serwerach hostów i AS/400 uwzględnia dynamiczne kursory niejednoznaczne, lecz produkt DB2 Universal Database uwzględnia niektóre dynamiczne kursory jednoznaczne. Aby uniknąć zamieszania, można podać dla DB2 Connect BLOCKING ALL.

Wielkość bloku w pliku konfiguracyjnym menedżera baz danych DB2 należy podać, korzystając z Procesora wiersza komend, Control Center lub funkcji API w sposób podany w podręcznikach Administrative API Reference i Command Reference.

Atrybuty pakietu

Pakiet ma następujące atrybuty:

Identyfikator kolekcji
Identyfikator kolekcji. Można go podać w komendzie PREP.

Właściciel
Identyfikator właściciela pakietu. Można go podać w komendzie PREP lub BIND.

Twórca
Nazwa użytkownika, który wykonał powiązanie pakietu.

Kwalifikator
Niejawny kwalifikator obiektów w pakiecie. Można go podać w komendzie PREP lub BIND.

Każdy serwer hosta i AS/400 ma ograniczenia użycia tych atrybutów:

DB2 Universal Database for OS/390
Wszystkie cztery atrybuty mogą być różne. Używanie różnych kwalifikatorów wymaga specjalnych uprawnień administracyjnych. Więcej informacji na temat warunków dotyczących używania tych atrybutów można znaleźć w podręczniku Command Reference dla DB2 Universal Database for OS/390.

DB2 for VSE & VM
Wszystkie atrybuty muszą być identyczne. Jeśli użytkownik USER1 utworzy plik powiązań (przy użyciu PREP), a użytkownik USER2 wykona rzeczywiste powiązanie, USER2 potrzebuje uprawnienia DBA, aby wykonać powiązanie za użytkownika USER1. Dla tych atrybutów jest używana tylko nazwa użytkownika USER1.

DB2 Universal Database for AS/400
Kwalifikator wskazuje nazwę kolekcji. Relacja między kwalifikatorami a własnością wpływa na przyznawanie i odbieranie uprawnień do obiektu. Nazwa użytkownika, który jest zalogowany, jest nazwą twórcy i właściciela obiektu, chyba że jest zakwalifikowana przy użyciu identyfikatora kolekcji, która jest właścicielem obiektu. Identyfikator kolekcji musi istnieć, zanim zostanie użyty jako kwalifikator.

DB2 Universal Database
Wszystkie cztery atrybuty mogą być różne. Aby można było używać innego właściciela, potrzebne są uprawnienia administratora oraz konsolidator musi mieć uprawnienia CREATEIN dla schematu (jeśli już istnieje).
Uwaga:DB2 Connect obsługuje komendę SET CURRENT PACKAGESET dla produktów DB2 Universal Database for OS/390 i DB2 Universal Database.

Łańcuchy C zakończone znakiem o kodzie zero

Opcja wiązania CNULREQD zmienia obsługę łańcuchów zakończonych znakiem o kodzie zero podanych przy użyciu opcji LANGLEVEL.

Sposób obsługi łańcuchów zakończonych znakiem o kodzie zero, gdy są przygotowane z opcją LANGLEVEL ustawioną na MIA lub SAA1 jest opisany w podręczniku Application Development Guide.

Domyślnie wartość CNULREQD jest ustawiona na YES. Powoduje to, że łańcuchy zakończone znakiem o kodzie zero są interpretowane zgodnie ze standardem MIA. Zaleca się ustawienie wartości CNULREQD na YES podczas łączenia z serwerem DB2 Universal Database for OS/390. Należy łączyć aplikacje kodowane w standardzie SAA1 (z uwzględnieniem łańcuchów zakończonych znakiem o kodzie zero) przy użyciu opcji CNULREQD ustawionej na NO. W przeciwnym wypadku łańcuchy zakończone znakiem o kodzie zero zostaną zinterpretowane zgodnie ze standardem MIA, nawet jeśli zostały przygotowane przy użyciu LANGLEVEL do obsługi SAA1.

Samodzielne zmienne SQLCODE i SQLSTATE

Samodzielne zmienne SQLCODE i SQLSTATE są obsługiwane przez opcje prekompilacji LANGLEVEL SQL92E, co opisano w ISO/ANS SQL92. Podczas prekompilacji zostanie wygenerowane ostrzeżenie SQL0020W wskazujące, że LANDLEVEL nie jest obsługiwany. Ostrzeżenie to dotyczy wyłącznie opcji wymienionych dla LANGLEVEL MIA w podręczniku Command Reference, które są podzbiorem LANGLEVEL SQL92E.

Definiowanie porządku sortowania

Różnice między kodami EBCDIC i ASCII powodują różnice w porządku sortowania w różnych produktach obsługujących bazy danych oraz mają wpływ na klauzule ORDER BY i GROUP BY. Jedynym sposobem zminimalizowania tych różnic jest utworzenie porządku zdefiniowanego przez użytkownika, który imituje porządek sortowania EBCDIC. Porządek leksykograficzny można podać tylko przy tworzeniu nowej bazy danych. Więcej informacji można znaleźć w podręcznikach Application Development Guide, Administrative API Reference i w Command Reference.
Uwaga:Tabele baz danych mogą być teraz zapisywane w produkcie DB2 Universal Database for OS/390 w formacie ASCII. Umożliwia to szybszą wymianę danych między DB2 Connect a DB2 Universal Database for OS/390 i eliminuje potrzebę dostarczania procedur obsługi pól, które w przeciwnym wypadku musiałyby zostać użyte w celu konwersji danych i zmiany ich kolejności.

Zarządzanie spójnością referencyjną

Różne systemy obsługują ograniczenia referencyjne w różny sposób:

DB2 Universal Database for OS/390
Indeks musi być utworzony według klucza podstawowego zanim przy jego pomocy będzie można utworzyć klucz obcy. Tabele mogą odwoływać się do siebie samych.

DB2 for VSE & VM
W przypadku klucza obcego indeks jest tworzony automatycznie. Tabele nie mogą odwoływać się do siebie samych.

DB2 Universal Database for AS/400
W przypadku klucza obcego indeks jest tworzony automatycznie. Tabele mogą odwoływać się do siebie samych.

DB2 Universal Database
W przypadku baz danych produktu DB2 Universal Database indeks jest tworzony automatycznie dla ograniczenia przez unikalność; dotyczy to także klucza podstawowego. Tabele mogą odwoływać się do siebie samych.

Pozostałe zasady różnią się w zależności od poziomu kaskady.

Blokowanie

Sposób, w jaki serwer baz danych realizuje blokowanie, może mieć wpływ na niektóre aplikacje. Na przykład aplikacji, które wykorzystują blokady na poziomie wiersza i poziomie odseparowania stabilności kursora, nie można łatwo przenieść do systemów wykonujących blokowanie na poziomie pakietu. Ze względu na wymienione różnice może zaistnieć konieczność dopasowania aplikacji.

Produkty DB2 Universal Database for OS/390 i DB2 Universal Database mają możliwość oczekiwania na blokadę i wysłania do oczekujących aplikacji kodu powrotu z informacją o błędzie.

Różnice w kodach SQLCODE i stanach SQLSTATE

Różne produkty relacyjnych baz danych IBM nie zawsze zwracają te same kody SQLCODE dla takich samych błędów. Można rozwiązać ten problem na dwa sposoby:

Używanie katalogu systemowego

Katalogi systemowe różnią się w zależności od produktów IBM obsługujących bazy danych. Wiele różnic można ukryć, wykorzystując widoki. Informacje na ten temat można znaleźć w dokumentacji dotyczącej konkretnego serwera baz danych.

Funkcje katalogu interfejsu poziomu wywołania (CLI) omijają ten problem dzięki obsłudze takich samych funkcji API i dzięki zbiorom wynikowym dla zapytań dotyczących katalogu dla całej rodziny DB2.

Przepełnienia podczas konwersji numerycznych dla przypisań wyszukiwania

Przepełnienie podczas konwersji numerycznej dla przypisań wyszukiwania może być obsługiwane w różny sposób przez różne produkty IBM obsługujące relacyjne bazy danych. Przykładem może być wybór kolumny danych zmiennopozycyjnych dla zmiennej języka bazowego typu całkowitoliczbowego z produktów DB2 Universal Database for OS/390 i DB2 Universal Database. Podczas konwersji wartości zmiennopozycyjnych na wartości całkowitoliczbowe może powstać przepełnienie. Domyślnie DB2 Universal Database for OS/390 zwraca do aplikacji ostrzeżenie SQLCODE oraz wartość pustą. Produkt DB2 Universal Database zwraca natomiast błąd przepełnienia podczas konwersji. Zaleca się, aby aplikacje unikały przepełnienia podczas konwersji wartości numerycznych dla przypisań wyszukiwania przez sprowadzanie wartości do zmiennych języka bazowego właściwego rozmiaru.

Poziomy odseparowania

DB2 Connect akceptuje następujące poziomy odseparowania podczas wykonywania dla aplikacji komend prep lub bind:

RR
Repeatable Read (odczyt powtarzalny),

RS
Read Stability (stabilność odczytu),

CS
Cursor Stability (stabilność kursora),

UR
Uncommitted Read (odczyt niezatwierdzony),

NC
No Commit (brak zatwierdzenia).

Poziomy odseparowania są uszeregowane w porządku od najwyższego stopnia ochrony do najniższego. Jeśli serwer hosta lub AS/400 nie obsługuje podanego poziomu odseparowania, zostanie użyty najbliższy z wyższych obsługiwanych poziomów.

Tabela 2 zawiera wynik każdego poziomu odseparowania na każdym serwerze aplikacji hosta lub AS/400.

Tabela 2. Poziomy odseparowania
DB2 Connect DB2 Universal Database for OS/390 DB2 for VSE & VM DB2 Universal Database for AS/400 DB2 Universal Database
RR RR RR uwaga 1 RR
RS uwaga 2 RR COMMIT(*ALL) RS
CS CS CS COMMIT(*CS) CS
UR uwaga 3 CS COMMIT(*CHG) UR
NC uwaga 4 uwaga 5 COMMIT(*NONE) UR

Uwagi:

  1. W produkcie DB2 Universal Database for AS/400 nie ma równoważnej opcji COMMIT dla RR. DB2 Universal Database for AS/400 obsługuje RR przez blokowanie całej tabeli.

  2. Wyniki poziomu RR dla wersji 3.1, poziomu RS dla wersji 4.1 z APAR PN75407 i dla wersji 5.1.

  3. Wyniki poziomu CS dla wersji 3.1, poziomu UR dla wersji 4.1 i dla wersji 5.1.

  4. Wyniki poziomu CS dla wersji 3.1, poziomu UR dla wersji 4.1 z APAR PN60988 i dla wersji 5.1.

  5. Poziom odseparowania NC nie jest obsługiwany dla produktu DB2 for VSE & VM.

W produkcie DB2 Universal Database for AS/400 można korzystać z tabeli, która nie jest zapisywana w dzienniku, jeśli aplikacja jest powiązana z poziomem odseparowania UR i tworzeniem bloków ustawionym na ALL lub jeśli poziom odseparowania jest ustawiony na NC.

Procedury zapisane w bazie

Program budujący procedury zapisane w bazie

Program budujący procedury zapisane w bazie DB2 udostępnia łatwe w użyciu środowisko projektowania przeznaczone do tworzenia, instalowania i testowania procedur zapisanych w bazie. Pozwala skoncentrować się na tworzeniu logiki procedur zapisanych w bazie, a nie na szczegółach związanych z rejestrowaniem, tworzeniem i instalowaniem procedur zapisanych w bazie na serwerze DB2. Ponadto za pomocą programu budującego procedury zapisane w bazie można projektować te procedury w jednym systemie operacyjnym, natomiast budować je w innych systemach operacyjnych serwerów.

Program budujący procedury zapisane w bazie jest to aplikacja graficzna, która obsługuje proces szybkiego projektowania. Za pomocą programu budującego procedury zapisane w bazie można wykonać następujące zadania:

Program budujący procedury zapisane w bazie można uruchamiać z grupy programów DB2 Universal Database jako oddzielną aplikację, można go także uruchamiać z dowolnej z następujących aplikacji służących do projektowania:

Program budujący procedury zapisane w bazie można także uruchomić z Centrum sterowania dla DB2 for OS/390. Program budujący procedury zapisane w bazie można uruchamiać z menu narzędzi centrum sterowania, z paska narzędzi lub z folderu procedur zapisanych w bazie (Stored Procedures), jako osobny proces. Ponadto z okna projektu programu budującego procedury zapisane w bazie można wyeksportować jedną lub więcej wybranych procedur SQL zapisanych w bazie, do serwera DB2 for OS/390, do określonego pliku, który można uruchomić za pomocą Procesora wiersza komend (CLP).

Program budujący procedury zapisane w bazie zarządza pracą za pomocą projektów. Każdy projekt utworzony w programie budującym procedury zapisane w bazie zapisuje połączenia z wybranymi bazami danych, takimi jak na przykład serwery DB2 for OS/390. Ponadto można tworzyć filtry przeznaczone do wyświetlania podzbiorów procedur zapisanych w każdej bazie danych. Podczas otwierania nowego lub istniejącego projektu z programu budującego procedury zapisane w bazie można filtrować te procedury, a dzięki temu przeglądać je na podstawie ich nazw, schematów, języka lub identyfikatora kolekcji (tylko w systemie OS/390).

Informacje o połączeniach zapisywane są w projekcie z programu budującego procedury zapisane w bazie; a zatem, podczas otwierania istniejącego projektu użytkownikowi wyświetlana jest automatycznie zachęta do wprowadzenia identyfikatora i hasła użytkownika w bazie danych. Za pomocą kreatora wstawiania procedur SQL zapisanych w bazie, można tworzyć takie procedury SQL na serwerze DB2 for OS/390. Dla procedur SQL zapisanych w bazie, które budowane są na serwerze DB2 for OS/390 można ustawić specjalne opcje kompilacji, wstępnej konsolidacji, konsolidacji, powiązania, czasu wykonania, środowiska i opcje zewnętrznej ochrony.

Ponadto można uzyskać informacje o kosztach, dotyczące procedur SQL zapisanych w bazie, włącznie z informacjami o czasie pracy procesora oraz inne informacje o kosztach związanych z DB2 dla wątku, w którym uruchomiona została procedura SQL zapisana w bazie. W szczególności można uzyskać informacje dotyczące kosztów czasu oczekiwania w rywalizacji zatrzask/blokada, liczby pobranych stron, liczby odczytów we/wy i liczby zapisów we/wy.

Aby uzyskać informacje o kosztach, program budujący procedury zapisane w bazie łączy się z serwerem DB2 for OS/390, wykonuje instrukcję SQL i wywołuje procedurę zapisaną w bazie (DSNWSPM), aby dowiedzieć się, ile czasu pracy procesora wykorzystała procedura SQL zapisana w bazie.

Złożona instrukcja SQL NOT ATOMIC

Złożony SQL umożliwia grupowanie wielu instrukcji SQL w bloki wykonywalne. Może to wpłynąć na ograniczenie nakładu pracy sieci i skrócić czas odpowiedzi.

DB2 Connect obsługuje złożoną instrukcję SQL NOT ATOMIC. Oznacza to, że przetwarzanie złożonego SQL jest kontynuowane po wystąpieniu błędu. (W przypadku złożonej instrukcji SQL ATOMIC, która nie jest obsługiwana przez DB2 Connect, błąd spowoduje wycofanie zmian związanych z całą grupą złożonych instrukcji SQL).

Instrukcje będą nadal wykonywane, dopóki nie zostaną przerwane przez serwer aplikacji. Generalnie wykonywanie złożonej instrukcji SQL zostanie zatrzymane tylko w przypadku wystąpienia poważnych błędów.

Złożona instrukcja SQL NOT ATOMIC może być używana ze wszystkimi obsługiwanymi serwerami aplikacji hosta lub AS/400.

Jeśli wystąpi wiele błędów SQL, stany SQLSTATE pierwszych siedmiu błędnych instrukcji są zwracane w polu obszaru komunikacyjnego SQL SQLERRMC wraz z komunikatem informującym, że wystąpiło wiele błędów. Więcej informacji na ten temat można znaleźć w podręczniku SQL Reference.

Aktualizacja wielostanowiskowa za pomocą DB2 Connect

DB2 Connect zezwala użytkownikowi na wykonywanie aktualizacji w wielu lokalizacjach, zwanej również zatwierdzaniem dwufazowym. Aktualizacja w wielu lokalizacjach służy do aktualizacji wielu baz danych w ramach jednej rozproszonej jednostki pracy (DUOW). To, czy można skorzystać z tej możliwości, zależy od kilku czynników:

Instrukcje SQL hosta lub serwera AS/400 obsługiwane przez DB2 Connect

Następujące instrukcje są kompilowane pomyślnie i przetwarzane przez serwer hosta lub AS/400, lecz nie są przetwarzane przez systemy produktu DB2 Universal Database:

Instrukcje te są również obsługiwane przez procesor wiersza komend.

Następujące instrukcje są obsługiwane i przetwarzane przez serwer hosta lub AS/400, nie są jednak dodawane do pliku wiązania lub pakietu i nie są obsługiwane przez procesor wiersza komend:

Prekompilator przyjmuje następujące założenia:

Instrukcje SQL hosta lub serwera AS/400 nieobsługiwane przez DB2 Connect

Następujące instrukcje SQL nie są obsługiwane przez DB2 Connect, ani przez procesor wiersza komend:

Instrukcje rozszerzonego dynamicznego SQL produktu DB2 for VSE & VM są odrzucane z kodem 104 i kodem błędu składni SQLCODE.


[ Początek strony | Poprzednia strona | Następna strona | Spis treści | Indeks ]