DB2 Connect позволява на приложни програми да имат достъп до данни в DB2 бази данни на сървъри System/390 и AS/400. Например приложение, което работи под Windows може да има достъп до данни в DB2 Universal Database за OS/390 база данни. Можете да създадете нови приложения или да промените съществуващите, за да работят в хост или AS/400 среда. Освен това можете да разработите приложения в една среда и да ги прехвърлите в друга.
DB2 Connect ви позволява да използвате следните API с продукти на хост база данни като DB2 Universal Database за OS/390, в случай, че елементът се поддържа от продукта на хост базата данни:
Някои SQL изрази се различават между различните релационни бази данни. Може да срещнете SQL изрази, които са:
SQL изразите в първите две категории имат големи възможности за прехвърляне, докато тези в третата категория ще трябва най-напред да се променят. Като цяло SQL изразите в Data Definition Language (DDL) не могат толкова лесно да се прехвърлят, колкото тези в Data Manipulation Language (DML).
DB2 Connect приема някои SQL изрази, които не се поддържат от DB2 Universal Database. DB2 Connect предава тези изрази към хоста или AS/400 сървъра. Информация за ограниченията на различните платформи, като максималната ширина на колона вижте в SQL Справочник.
Ако преместите CICS приложение от OS/390 или VSE, за да работи под друг CICS продукт (например CICS за AIX), то освен това може да осъществи достъп до OS/390 или VSE база данни с помощта на DB2 Connect. Повече информация потърсете в Ръководство за програмиране на CICS/6000 приложения и Настройване и работа на CICS.
Когато програмирате в хост или AS/400 среда, трябва да разгледате следните специфични фактори:
DDL изразите се различават в рамките на различните бази данни на IBM, защото съхранението се обработва по различен начин от различните системи. При системите на хост или AS/400 сървър може да има няколко стъпки между проектирането на база данни и израза CREATE TABLE. Например серия от изрази може да конвертира един дизайн от логически обекти във физическото представяне на тези обекти на мястото за съхранение.
Предкомпилаторът предава много такива DDL оператори на хоста или AS/400 сървъра, когато предкомпилирате до хост или AS/400 сървър на база данни. Същите оператори няма да се предкомпилират спрямо база данни на системата, където се изпълнява приложението. Например в приложение за OS/2 операторът CREATE STORGROUP ще се предкомпилира успешно за DB2 Universal Database за OS/390 база данни, но не и при база данни DB2 за OS/2.
Като цяло DML операторите са лесни за прехвърляне. Операторите SELECT, INSERT, UPDATE и DELETE са подобни в рамките на различните релационни бази данни на IBM. Повечето приложения основно използват DML SQL оператори, които се поддържат от DB2 Connect програмата.
Когато се прехвърлят числени данни в DB2 Universal Database, типът на данните може да се промени. Числените и зонирани десетични типове SQLTYPE (поддържани от DB2 Universal Database за AS/400) се конвертират до фиксирани (пакетни) десетични типове SQLTYPE.
Смесените данни съдържат символи от разширената UNIX кодова таблица (EUC), двубайтовата кодова таблица (DBCS) и еднобайтовата кодова таблица (SBCS) в една и съща колона. На системи, които съхраняват данни в EBCDIC (OS/390, OS/400, VSE, and VM), символите shift-out и shift-in маркират началото и края на двубайтовите данни. На системите, които съхраняват данните в ASCII (като OS/2 и UNIX), не са необходими символите shift-in и shift-out.
Ако вашето приложение прехвърля едно- и двубайтови данни от ASCII система в EBCDIC система, внимавайте да оставите достатъчно място за символите shift. При всяко преминаване от SBCS до DBCS данни добавете 2 байта към дължината на данните. За по-голяма съвместимост използвайте низове с променлива дължина в приложенията, които използват смесени данни.
Дългите полета (низове по-дълги от 254 символа) се обработват по различен начин от различните системи. Хост или AS/400 сървър може да поддържа само подмножество от скаларните функции за дълги полета, например DB2 Universal Database за OS/390 поддържа само функциите LENGTH и SUBSTR върху дълги полета. Освен това хост или AS/400 сървър може да изисква различна обработка за определени SQL оператори; например DB2 за VSE и VM изисква с оператора INSERT да се използва само хост променлива, SQLDA или NULL стойност.
Типът данни LOB се поддържа от DB2 Connect.
Само отделни дефинирани от потребителя типове се поддържат от DB2 Connect. Абстрактните типове данни не се поддържат.
Типът данни ROWID се обработва от DB2 Connect като VARCHAR за двоични данни.
Осем байтов (64-битов) integer се поддържа от DB2 Connect. Вътрешният тип данни BIGINT се използва за поддръжка на броя редове в таблици в много големи бази данни, като се запазва точността на данните.
Всяка система за управление на релационна база данни на IBM осигурява различни степени на обособеност за SQL операторите GRANT и REVOKE. Проверете специфичните за продукта публикации, за да проверите подходящите SQL изрази, които да се използват за всяка система за управление на база данни.
DB2 Connect поддържа версиите на CONNECT TO и CONNECT RESET на оператора CONNECT, както и CONNECT без параметри. Ако приложение подаде SQL оператор, без най-напред да изпълни явния оператор за свързване CONNECT TO, се изпълнява неявно свързване към сървъра за приложения по подразбиране (ако е дефиниран).
Когато се свържете към база данни, в полето SQLERRP на SQLCA се връща информация за системата за управление на релационна база данни. Ако сървърът на приложенията е релационна база данни на IBM, първите три байта на SQLERRP съдържат едно от следните:
Ако използвате оператор CONNECT TO или null CONNECT, докато използвате DB2 Connect, токенът с кода на страната или територията в полето SQLERRMC на SQLCA се връща като празен; CCSID на сървъра на приложенията се връща в токена на кодовата страница или кодовата таблица.
Можете явно да прекъснете връзката, като използвате оператора CONNECT RESET (за свързване тип 1), операторите RELEASE и COMMIT [за свързване тип 2) или оператор DISCONNECT (и за двата типа свързване, но не в среда на TP следене).
Ако връзката не е прекъсната явно и приложението приключи нормално, DB2 Connect записва безусловно получените в резултат данни.
Забележка: | Приложението може да получи съобщения SQLCODE, които да посочват грешки, но независимо от това да приключи нормално; DB2 Connect записва данните в този случай. Ако не искате данните да се запишат, трябва да използвате командата ROLLBACK. |
Командата FORCE ви позволява да прекъснете връзката на избрани потребители или всички потребители към базата данни. Тази функция се поддържа за хост или AS/400 сървър на база данни; потребителят може да бъде принуден да се прекъсне връзката от DB2 Connect работната станция.
Има някои разлики в предкомпилаторите за различните системи на релационни бази данни на IBM. Предкомпилаторът за DB2 Universal Database се различава от предкомпилаторите за хост или AS/400 сървър в следното:
Програмата DB2 Connect поддържа възможностите за свързване на блокове на мениджъра на DB2 база данни:
Програмата DB2 Connect използва размера на блока, дефиниран в конфигурационния файл на мениджъра на DB2 базата данни за полето RQRIOBLK. Текущите версии на DB2 Connect поддържат размери на блокове до 32 767. Ако в конфигурационния файл на мениджъра на DB2 базата данни се определят по-големи стойности, DB2 Connect използва стойността 32 767, но не инициализира конфигурационния файл на мениджъра на DB2 базата данни. Създаването на блокове се извършва по един и същи начин с помощта на един и същи размер на блок за динамичен и статичен SQL.
Забележка: | Повечето хост или AS/400 сървъри разглеждат динамичните указатели като неопределени, но DB2 Universal Database системите разглеждат някои динамични указатели като дефинирани. За да се избегне объркване, можете да определите BLOCKING ALL с DB2 Connect. |
В конфигурационния файл на мениджъра на DB2 базата данни определете размера на блока, като използвате CLP, Център за управление или API, както е посочено в Административен API Справочник и Справочник на командите.
Пакет има следните атрибути:
Всеки хост или AS/400 сървър има ограничения при използването на тези атрибути:
Забележка: | DB2 Connect осигурява поддръжка на командата SET CURRENT PACKAGESET за DB2 Universal Database за OS/390 и DB2 Universal Database. |
Опцията за свързване CNULREQD замества работата с низове без символ за край, които са определени с помощта на опцията LANGLEVEL.
Информация за това как се обслужват низове без символ за край, когато са подготвени с опцията LANGLEVEL, установена на MIA или SAA1, ще намерите в Ръководство за разработка на приложения.
По подразбиране CNULREQD се установява на YES. Така низовете без символ за край ще се интерпретират според MIA стандартите. При свързване към a DB2 Universal Database за OS/390 сървър се препоръчва CNULREQD да се установи на YES. Трябва да свържете приложенията, кодирани според SAA1 стандартите (по отношение на низовете без символ за край), като установите опцията CNULREQD на NO. В противен случай низовете без символ за край ще се интерпретират според MIA стандартите, дори ако са подготвени с опция LANGLEVEL, установена на SAA1.
Самостоятелните променливи SQLCODE и SQLSTATE, както са дефинирани в ISO/ANS SQL92, се поддържат от опцията за предкомпилиране LANGLEVEL SQL92E. По време на предкомпилиране ще се генерира предупреждение SQL0020W, което показва, че LANGLEVEL не се поддържа. Това предупреждение се отнася само за компонентите, изброени под LANGLEVEL MIA в Справочник на командите, което е подмножество на LANGLEVEL SQL92E.
Разликите между EBCDIC и ASCII предизвикват разлики в реда на сортиране в различните бази данни и освен това влияят върху клаузите ORDER BY и GROUP BY. Един начин да се намалят тези разлики е да се създаде дефинирана от потребителя последователност, която да замества реда за сортиране EBCDIC. Можете да определите последователност, само когато създавате нова база данни. Повече информация потърсете в Ръководство за разработка на приложения, Административен API Справочник и Справочник на командите.
Забележка: | Таблиците на базата данни сега могат да се съхраняват в DB2 Universal Database за OS/390 в ASCII формат. Това позволява по-бърз обмен на данни между DB2 Connect и DB2 Universal Database за OS/390, като премахва необходимостта да се осигуряват процедури за полета, които в противен случай трябва да се използват за конвертиране на данните и преподреждането им. |
Различните системи по различен начин обработват референциалните ограничения:
Други правила се различават по отношение степента на каскадност.
Начинът, по който сървърът на базата данни изпълнява заключването може да повлияе върху някои приложения. Например приложенията, които са изградени на базата на заключване на ниво ред и ниво на изолация на защита на ниво ред не могат директно да се прехвърлят към системи, които изпълняват заключване на ниво страница. Поради тези скрити разлики може да се наложи приложенията да се пренастройват.
DB2 Universal Database за OS/390 и DB2 Universal Database има възможност за таймаут на заключване и да изпратят код за грешка на чакащите приложения.
Различните релационни бази данни на IBM не винаги генерират едни и същи кодове SQLCODE за подобни грешки. Можете да решите този проблем по един от следните начини:
SQLSTATE имат приблизително едно и също значение в различните видове бази данни и те генерират код SQLSTATE, който отговаря на SQLCODE.
По подразбиране DB2 Connect трансформира кодовете SQLCODE и токените от всеки IBM хост или AS/400 сървър на вашата система DB2 Universal Database. Можете да определите ваш собствен файл за трансформиране на SQLCODE, ако искате да замените трансформирането по подразбиране или използвате сървър на база данни, който няма SQLCODE трансформиране (сървър на база данни, който не е на IBM). Освен това можете да изключите SQLCODE трансформирането.
За повече информация вижте Преобразуване на SQLCODE.
Системните каталози се различават между различните бази данни на IBM. Много от разликите могат да се скрият с използването на производни таблици. Информация потърсете в документацията на сървъра на база данни, който използвате.
Функциите на каталог в CLI заобикалят този проблем, като предоставят поддръжка на същия API и резултатни набори за заявките за каталог в рамките на фамилията DB2.
Препълванията при числено конвертиране вследствие присвояване при извличане може да се обработва по различен начин от различните релационни бази данни на IBM. Например да приемем, че се извлича колона с данни от тип плаваща запетая в хост променлива с тип integer от DB2 Universal Database за OS/390 и от DB2 Universal Database. При конвертирането на стойност с тип плаваща запетая в стойност от тип integer, може да възникне препълване. По подразбиране DB2 Universal Database за OS/390 ще върне предупреждение SQLCODE и стойност NULL на приложението. За разлика DB2 Universal Database ще върне грешка за препълване при конвертиране. Препоръчва че, приложенията да избягват препълванията при числени конвертирания, възникнали при присвояване след извличане, като се поставят в хост променливи с подходящи размери.
DB2 Connect приема следните нива на изолация, когато подготвите или свържете приложение:
Нивата на изолация са изброени от тези с най-силна защита до най-слаба защита. Ако хост или AS/400 сървър не поддържа нивото на изолация, което определите, се използва следващото по-високо поддържано ниво.
Таблица 2 показва резултата от всяко ниво на изолация на всеки хост
или AS/400 сървър на приложения.
DB2 Connect | DB2 Universal Database за OS/390 | DB2 за VSE и VM | DB2 Universal Database за AS/400 | DB2 Universal Database |
---|---|---|---|---|
RR | RR | RR | note 1 | RR |
RS | note 2 | RR | COMMIT(*ALL) | RS |
CS | CS | CS | COMMIT(*CS) | CS |
UR | note 3 | CS | COMMIT(*CHG) | UR |
NC | note 4 | note 5 | COMMIT(*NONE) | UR |
Забележки:
|
При DB2 Universal Database за AS/400 имате достъп до нежурнална таблица, ако приложението е свързано с ниво на изолация UR и създаване на блокове е установено на ALL, или ако нивото на изолация е NC.
Клиентска програма може да се обърне към сървър чрез оператора SQL CALL. В този случай различните сървъри работят по малко по-различен начин.
Всички оператори CALL към DB2 за AS/400 от REXX/SQL трябва динамично да се подготвят и изпълнят от приложението, тъй като варианта на оператора CALL в REXX/SQL се трансформира до CALL USING DESCRIPTOR.
Синтаксисът на оператора SQL CALL можете да намерите в SQL Справочник. За информация как да използвате запомнени процедури, когато създавате приложни програми, се обърнете към Ръководство за разработка на приложения.
Можете да се обърнете към сървърна програма DB2 Universal Database при същите правила за параметрите, които сървърните програми използват на DB2 Universal Database за OS/390, DB2 Universal Database за AS/400, или DB2 за VSE и VM. За информация за обръщение към DB2 Universal Database запомнени процедури се обърнете към Ръководство за разработка на приложения. Повече информация за правилата при използване на параметри на други платформи ще намерите в документацията на DB2 за съответната платформа.
Всички SQL оператори в запомнени процедури се изпълняват като част от SQL единица работа, стартирана от клиентска SQL програма.
Между DB2 Universal Database, системите прехвърлят каквото поставите в променливите индикатори. Обаче когато използвате DB2 Connect, можете да прехвърлите само 0, -1 и -128 в променлива индикатор.
Сървърна програма на DB2 Universal Database може да обнови SQLCA, за да върне грешка или предупреждение, но запомнена процедура на DB2 Universal Database за OS/390 или DB2 Universal Database за AS/400 не поддържа тази възможност. Ако искате да върнете код за грешка от вашата запомнена процедура, трябва да го предадете като параметър. SQLCODE и SQLCA се определя само от сървъра за откритите от системата грешки.
DB2 Stored Procedure Builder осигурява лесна за използване среда за създаване, инсталиране и тестване на запомнени процедури. Позволява ви да се съсредоточите върху създаването на логиката на запомнената процедура, вместо върху подробностите, свързани с регистрирането, изграждането и инсталирането на запомнената процедура на DB2 сървър. Освен това при Stored Procedure Builder можете да разработите запомнени процедури на една операционна система и да ги изградите на други сървърни операционни системи.
Stored Procedure Builder е графично приложение, което поддържа бърза разработка. С помощта на Stored Procedure Builder можете да изпълните следните задачи:
Можете да стартирате Stored Procedure Builder като отделно приложение от DB2 Universal Database програмната група или от някое от следните приложения за разработка:
Освен това можете да стартирате Stored Procedure Builder от Центъра за управление на DB2 за OS/390. Можете да стартирате Stored Procedure Builder като отделен процес от менюто Инструменти на центъра за управление, от линията с инструменти или от папка Stored prcedures. Освен това от прозореца Stored Procedure Builder Project можете да експортирате една или повече избрани SQL запомнени процедури, вградени в DB2 за OS/390 сървър до определен файл, който може да работи в рамките на процесора за обработка на команди (CLP).
Stored Procedure Builder управлява работата ви, като използва проекти. Във всеки проект на Stored Procedure Builder се записват вашите свързвания към определени бази данни, като DB2 за OS/390 сървъри. Допълнително можете да създадете филтри, които да представят подмножества на запомнените процедури на всяка база данни. Когато отваряте нов или съществуващ проект на Stored Procedure Builder, можете да филтрирате запомнените процедури, така че да виждате само някои на база на тяхното име, схема, език или идентификатор (само за OS/390).
Информацията за свързване се записва в проекта на Stored Procedure Builder; следователно, когато отворите съществуващ проект, автоматично се появява промпт, за да въведете вашия потребителски идентификатор и парола за базата данни. Като използвате помощника Inserting SQL Stored Procedure, можете да вградите SQL запомнени процедури в DB2 за OS/390 сървър. За SQL запомнена процедура, вградена в DB2 за OS/390 сървър, можете да определите специфични параметри за компилиране, предварителни връзки, връзки, обвързване, време за изпълнение, WLM обкръжение и външни защити.
Допълнително можете да получите информация за SQL разходите за SQL запомнената процедура, включително информация за процесорното време, други DB2 разходи за нишката, в която работи SQL запомнената процедура. По-специално можете да получите информация за разходите, свързани с времето за изчакване при повторно заключване, броя на извлечените страници, броя на прочетените Входно/Изходни елементи, броя на записаните Входно/Изходни елементи.
За да получите информация за разходите, Stored Procedure Builder се свързва към DB2 за OS/390 сървър, изпълнява SQL израз и се обръща към запомнена процедура (DSNWSPM), за да разбере колко процесорно време е използвала SQL запомнената процедура.
SQL блокът позволява няколко SQL оператора да се групират в отделен изпълним блок. Така може да се намали натоварването на мрежата и времето за отговор.
DB2 Connect поддържа НЕ АТОМАРЕН SQL блок. Това означава, че обработката на SQL блока продължава след грешка. (При АТОМАРЕН SQL блок, който не се поддържа от DB2 Connect, при възникване на грешка ще върне обратно цялата група на SQL блока.)
Операторите ще продължат изпълнението, докато се прекъсне от сървъра на приложения. Като цяло изпълнението на SQL блок от оператори ще се спре само в случай на сериозни грешки.
НЕ АТОМАРЕН SQL блок може да се използва с всички от поддържаните хост или AS/400 сървъри на приложения.
Ако възникнат няколко SQL грешки, кодовете SQLSTATE на първите седем оператора, които не са изпълнени, ще се върнат в полето SQLERRMC на SQLCA със съобщение, че са възникнали няколко грешки. За допълнителна информация се обърнете към SQL Справочник.
DB2 Connect ви позволява да изпълните многосайтово обновяване, също така известно като обновяване на няколко бази данни в рамките на една разпределена единица работа (DUOW). Дали можете да използвате тази възможност зависи от редица фактори:
Горното е вярно за собствени DB2 UDB приложения и приложения, координирани от външен Монитор на Обработка на транзакции (TP) като IBM TXSeries, CICS за Open Systems, BEA Tuxedo, Encina Monitor и Microsoft Transaction Server.
Забележка: | За допълнителна информация за XA концентратор вижте DB2 Connect концентратор за връзки. |
в DB2 UDB Версия 7 (включително DB2 UDB EE, DB2 UDB EEE и DB2 Connect EE), DB2 SPM е усъвършенстван, като поддържа свързване по TCP/IP. Ако приложението е собствено приложение на DB2 UDB, тогава не е необходимо използването на DB2 SPM при двуфазово записване.
Ако се използва общ DB2 Connect Enterprise Edition сървър от собствени DB2 приложения и TP приложения за следене, за да се осъществи достъп до хост данни през TCP/IP, тогава трябва да се използва DB2 SPM.
Ако се използва отделен DB2 Connect Enterprise Edition сървър за достъп до хост данни с помощта едновременно на SNA и TCP/IP мрежови протоколи и е необходим двуфазово записване, тогава трябва да се използва DB2 SPM. Това е вярно както за DB2 приложенията, така и за TP приложенията за следене.
Забележки:
Силно препоръчваме всички клиенти, които имат достъп до базите данни DB2 Universal Database Версия 7 и DB2 Universal Database за OS/390 версия 5 да са DB2 Universal Database Версия 7. DB2 версия 2.1 клиенти не могат да инициират транзакции с двуфазово записване, ако в транзакцията участват база данни DB2 Universal Database за OS/390 версия 5.
Следните оператори се компилират успешно за хост или AS/400 сървър, но не и за обработка върху DB2 Universal Database системи:
Тези оператори се поддържат и от процесор за обработка на команди.
Следните оператори се поддържат за обработка от хост или AS/400 сървър, но не са добавени към файла за свързване или пакета и не се поддържат от процесор за обработка на команди:
Предкомпилаторът извършва следните приемания:
Следните SQL оператори не се поддържат от DB2 Connect и не се поддържат от процесор за обработка на команди:
DB2 за VSE и VM допълнителните оператори от динамичния SQL се отхвърлят със SQLCODE -104 и синтактична грешка.