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:
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.
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.
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 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 (ł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.
Typ danych LOB jest obsługiwany przez DB2 Connect.
Tylko odrębne typy zdefiniowane przez użytkownika są obsługiwane przez DB2 Connect. Abstrakcyjne typy danych nie są obsługiwane.
Typ danych ROWID jest obsługiwany przez DB2 Connect jako VARCHAR dla danych bitowych.
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.
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.
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:
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.
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:
Opcje menedżera baz danych wiązania w bloki obsługiwane przez DB2 Connect są następujące:
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.
Pakiet ma następujące atrybuty:
Każdy serwer hosta i AS/400 ma ograniczenia użycia tych atrybutów:
Uwaga: | DB2 Connect obsługuje komendę SET CURRENT PACKAGESET dla produktów DB2 Universal Database for OS/390 i DB2 Universal Database. |
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 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.
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. |
Różne systemy obsługują ograniczenia referencyjne w różny sposób:
Pozostałe zasady różnią się w zależności od poziomu kaskady.
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óż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:
Kody SQLSTATE mają mniej więcej to samo znaczenie w różnych produktach obsługujących bazy danych, a produkty generują kody SQLSTATE, które odpowiadają kodom SQLCODE.
Domyślnie DB2 Connect odwzorowuje kody SQLCODE i znaczniki hosta lub serwera AS/400 IBM na produkt DB2 Universal Database. Użytkownik może podać własny plik odwzorowania SQLCODE, jeśli chce przesłonić domyślny sposób odwzorowania lub używa serwera baz danych, który nie ma odwzorowania kodów SQLCODE (nie pracuje na serwerze baz danych IBM). Można również wyłączyć odwzorowanie kodów SQLCODE.
Więcej informacji można znaleźć w podręczniku Odwzorowanie SQLCODE.
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ł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.
DB2 Connect akceptuje następujące poziomy odseparowania podczas wykonywania dla aplikacji komend prep lub bind:
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:
|
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.
Program typu klient może wywołać program serwera, wprowadzając instrukcję CALL SQL. W tym przypadku każdy serwer działa trochę inaczej niż pozostałe.
Wszystkie instrukcje DB2 for AS/400 REXX/SQL muszą być dynamicznie przygotowane i muszą być uruchamiane przez aplikacje, ponieważ instrukcja CALL zaimplementowana w REXX/SQL odpowiada instrukcji CALL USING DESCRIPTOR.
Składnia instrukcji SQL CALL jest opisana w podręczniku SQL Reference. Informacje na temat sposobu użycia procedur zapisanych w bazie podczas pisania aplikacji znajdują się w podręczniku Application Development Guide.
Program serwera działający dla produktu DB2 Universal Database można wywoływać z zastosowaniem tej samej konwencji dotyczącej parametrów, co programy serwera działające dla produktów DB2 Universal Database for OS/390, DB2 Universal Database for AS/400 lub DB2 for VSE & VM. Więcej informacji na temat wywoływania procedur zapisanych w bazie DB2 Universal Database, znajduje się w podręczniku Application Development Guide. Więcej informacji na temat konwencji użycia parametrów dla innej platformy znajduje się w dokumentacji produktu DB2 dla konkretnej platformy.
Wszystkie instrukcje SQL znajdujące się w procedurze zapisanej w bazie są wykonywane jako część jednostki pracy uruchamianej przez program typu klient SQL.
DB2 Universal Database przekazuje dowolne dane umieszczone w zmiennych sygnalizacyjnych, natomiast podczas korzystania z DB2 Connect można przekazać tylko zmienne sygnalizacyjne o wartościach 0, -1 i 128.
Program serwera działający dla produktu DB2 Universal Database może zaktualizować wartość w obszarze komunikacyjnym SQL, aby zwracała wszystkie informacje o błędach lub ostrzeżenia, jednak procedury zapisane w bazie w systemach DB2 Universal Database for OS/390 lub DB2 Universal Database for AS/400 nie mają takich możliwości. Jeśli mają być zwracane kody błędów z procedur zapisanych w bazie, należy je przekazać jako parametry. Kody SQLCODE i SQLCA są ustawiane przez serwer w przypadku wykrycia błędów przez system.
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ż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.
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:
Powyższe informacje są prawdziwe dla rodzimych aplikacji DB2 UDB i aplikacji koordynowanych przez zewnętrzny monitor przetwarzania transakcji, taki jak IBM TXSeries, CICS for Open Systems, BEA Tuxedo, Encina Monitor lub Microsoft Transaction Server.
Uwaga: | Aby uzyskać więcej informacji na temat BEA Tuxedo, należy zapoznać się z sekcją Korzystanie z produktu DB2 Connect i monitorów przetwarzania transakcji. Aby uzyskać więcej informacji na temat koncentratora XA, patrz Koncentrator połączeń DB2 Connect. |
Jeśli wspólny serwer DB2 Connect Enterprise Edition jest używany przez rodzime aplikacje DB2 i aplikacje monitorowania TP do uzyskiwania dostępu do danych hosta za pomocą połączeń TCP/IP, to należy używać menedżera momentu synchronizacji.
Jeśli do uzyskania dostępu do danych hosta używany jest jeden serwer DB2 Connect Enterprise Edition, korzystający z SNA i protokołów sieciowych TCP/IP oraz jest używane zatwierdzanie dwufazowe, należy używać menedżera momentu synchronizacji. Odnosi się to zarówno do aplikacji DB2, jak i do aplikacji korzystających z monitora TP.
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:
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.