Ръководство за потребителя

Програмиране в разпределена среда

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 среда, трябва да разгледате следните специфични фактори:

Използване на Data Definition Language (DDL)

DDL изразите се различават в рамките на различните бази данни на IBM, защото съхранението се обработва по различен начин от различните системи. При системите на хост или AS/400 сървър може да има няколко стъпки между проектирането на база данни и израза CREATE TABLE. Например серия от изрази може да конвертира един дизайн от логически обекти във физическото представяне на тези обекти на мястото за съхранение.

Предкомпилаторът предава много такива DDL оператори на хоста или AS/400 сървъра, когато предкомпилирате до хост или AS/400 сървър на база данни. Същите оператори няма да се предкомпилират спрямо база данни на системата, където се изпълнява приложението. Например в приложение за OS/2 операторът CREATE STORGROUP ще се предкомпилира успешно за DB2 Universal Database за OS/390 база данни, но не и при база данни DB2 за OS/2.

Използване на Data Manipulation Language (DML)

Като цяло 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)

Типът данни LOB се поддържа от DB2 Connect.

Дефинирани от потребителя типове (UDT)

Само отделни дефинирани от потребителя типове се поддържат от DB2 Connect. Абстрактните типове данни не се поддържат.

Тип данни ROWID

Типът данни ROWID се обработва от DB2 Connect като VARCHAR за двоични данни.

Тип данни 64-битов Integer (BIGINT)

Осем байтов (64-битов) integer се поддържа от DB2 Connect. Вътрешният тип данни BIGINT се използва за поддръжка на броя редове в таблици в много големи бази данни, като се запазва точността на данните.

Използване на Data Control Language (DCL)

Всяка система за управление на релационна база данни на IBM осигурява различни степени на обособеност за SQL операторите GRANT и REVOKE. Проверете специфичните за продукта публикации, за да проверите подходящите SQL изрази, които да се използват за всяка система за управление на база данни.

Свързване и прекъсване на връзката

DB2 Connect поддържа версиите на CONNECT TO и CONNECT RESET на оператора CONNECT, както и CONNECT без параметри. Ако приложение подаде SQL оператор, без най-напред да изпълни явния оператор за свързване CONNECT TO, се изпълнява неявно свързване към сървъра за приложения по подразбиране (ако е дефиниран).

Когато се свържете към база данни, в полето SQLERRP на SQLCA се връща информация за системата за управление на релационна база данни. Ако сървърът на приложенията е релационна база данни на IBM, първите три байта на SQLERRP съдържат едно от следните:

DSN
DB2 Universal Database за OS/390

ARI
DB2 за VSE и VM

QSQ
DB2 Universal Database за AS/400

SQL
DB2 Universal Database.

Ако използвате оператор 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 база данни:

UNAMBIG
Само дефинирани указатели са в блок (по подразбиране).

ALL
Неопределените указатели не са в блок.

NO
Указателите не са в блок.

Програмата 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 Справочник и Справочник на командите.

Атрибути на пакети

Пакет има следните атрибути:

идентификатор на колекция
Идентификаторът на пакета. Може да се определи с командата PREP.

Owner
Идентификатор за разпознаване на собственика на пакета. Може да се определи с команда PREP или BIND.

Създател
Името на потребителя, който свързва пакета.

Квалификатор
Неявен квалификатор за обекти в пакета. Може да се определи с команда PREP или BIND.

Всеки хост или AS/400 сървър има ограничения при използването на тези атрибути:

DB2 Universal Database за OS/390
Всичките четири атрибути може да са различни. Използването на различен квалификатор изисква специални права на администратор. За повече информация за условията при използването на тези атрибути се обърнете към Справочник на командите за DB2 Universal Database за OS/390.

DB2 за VSE и VM
Всички атрибути трябва да са идентични. Ако USER1 създаде свързан файл (с PREP), а USER2 изпълни действителното свързване, USER2 трябва да има DBA права, за да свърже вместо USER1. Само името на потребителя USER1 се използва за атрибутите.

DB2 Universal Database за AS/400
Квалификаторът посочва името на колекцията. От взаимовръзката между квалификаторите и правата на собственика зависи предоставянето или отнемането на правата върху обекта. Името на потребителя, който е влязъл в системата е създател и собственик, освен ако не е квалифициран от идентификатор на колекция, като в този случай собственикът е идентификаторът на колекцията. Идентификаторът на колекцията трябва да съществува, преди да се използва от квалификатора.

DB2 Universal Database
Всичките четири атрибути може да са различни. Използването на различен собственик изисква права на администратор и наличието на право на достъп CREATEIN до схемата (ако вече съществува).
Забележка:DB2 Connect осигурява поддръжка на командата SET CURRENT PACKAGESET за DB2 Universal Database за OS/390 и DB2 Universal Database.

C низове без символ за край

Опцията за свързване CNULREQD замества работата с низове без символ за край, които са определени с помощта на опцията LANGLEVEL.

Информация за това как се обслужват низове без символ за край, когато са подготвени с опцията LANGLEVEL, установена на MIA или SAA1, ще намерите в Ръководство за разработка на приложения.

По подразбиране CNULREQD се установява на YES. Така низовете без символ за край ще се интерпретират според MIA стандартите. При свързване към a DB2 Universal Database за OS/390 сървър се препоръчва CNULREQD да се установи на YES. Трябва да свържете приложенията, кодирани според SAA1 стандартите (по отношение на низовете без символ за край), като установите опцията CNULREQD на NO. В противен случай низовете без символ за край ще се интерпретират според MIA стандартите, дори ако са подготвени с опция LANGLEVEL, установена на SAA1.

Самостоятелен SQLCODE и SQLSTATE

Самостоятелните променливи 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 за VSE и VM
За външния ключ автоматично се създава индекс. Таблиците не могат да се обръщат към себе си.

DB2 Universal Database за AS/400
За външния ключ автоматично се създава индекс. Таблиците могат да се обръщат към себе си.

DB2 Universal Database
При DB2 Universal Database базите данни автоматично се създава индекс за уникално ограничение, включително първичен ключ. Таблиците могат да се обръщат към себе си.

Други правила се различават по отношение степента на каскадност.

Заключване

Начинът, по който сървърът на базата данни изпълнява заключването може да повлияе върху някои приложения. Например приложенията, които са изградени на базата на заключване на ниво ред и ниво на изолация на защита на ниво ред не могат директно да се прехвърлят към системи, които изпълняват заключване на ниво страница. Поради тези скрити разлики може да се наложи приложенията да се пренастройват.

DB2 Universal Database за OS/390 и DB2 Universal Database има възможност за таймаут на заключване и да изпратят код за грешка на чакащите приложения.

Разлики в SQLCODE и SQLSTATE

Различните релационни бази данни на IBM не винаги генерират едни и същи кодове 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 приема следните нива на изолация, когато подготвите или свържете приложение:

RR
Защита при повторно четене

RS
Защита при четене

CS
Защита на ниво ред

UR
Защита при четене

NC
Без комит

Нивата на изолация са изброени от тези с най-силна защита до най-слаба защита. Ако хост или AS/400 сървър не поддържа нивото на изолация, което определите, се използва следващото по-високо поддържано ниво.

Таблица 2 показва резултата от всяко ниво на изолация на всеки хост или AS/400 сървър на приложения.

Таблица 2. Нива на изолация
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

Забележки:

  1. Няма еквивалентна опция COMMIT на DB2 Universal Database за AS/400, която да съответства на RR. DB2 Universal Database за AS/400 поддържа RR като заключва цялата таблица.

  2. В резултат се получава RR за версия 3.1 и RS за версия 4.1 с APAR PN75407 или версия 5.1.

  3. В резултат се получава CS за версия 3.1 и UR за версия 4.1 или версия 5.1.

  4. В резултат се получава CS за версия 3.1 и UR за версия 4.1 с APAR PN60988 или версия 5.1.

  5. Ниво на изолация NC не се поддържа на DB2 за VSE и VM.

При DB2 Universal Database за AS/400 имате достъп до нежурнална таблица, ако приложението е свързано с ниво на изолация UR и създаване на блокове е установено на ALL, или ако нивото на изолация е NC.

Запомнени процедури

Stored Procedure Builder

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 блокът позволява няколко SQL оператора да се групират в отделен изпълним блок. Така може да се намали натоварването на мрежата и времето за отговор.

DB2 Connect поддържа НЕ АТОМАРЕН SQL блок. Това означава, че обработката на SQL блока продължава след грешка. (При АТОМАРЕН SQL блок, който не се поддържа от DB2 Connect, при възникване на грешка ще върне обратно цялата група на SQL блока.)

Операторите ще продължат изпълнението, докато се прекъсне от сървъра на приложения. Като цяло изпълнението на SQL блок от оператори ще се спре само в случай на сериозни грешки.

НЕ АТОМАРЕН SQL блок може да се използва с всички от поддържаните хост или AS/400 сървъри на приложения.

Ако възникнат няколко SQL грешки, кодовете SQLSTATE на първите седем оператора, които не са изпълнени, ще се върнат в полето SQLERRMC на SQLCA със съобщение, че са възникнали няколко грешки. За допълнителна информация се обърнете към SQL Справочник.

Многосайтово обновяване с DB2 Connect

DB2 Connect ви позволява да изпълните многосайтово обновяване, също така известно като обновяване на няколко бази данни в рамките на една разпределена единица работа (DUOW). Дали можете да използвате тази възможност зависи от редица фактори:

Забележки:

  1. Базите данни на DB2 Common сървър версия 2.1 могат да се обновят с двуфазов комит в единица работа само когато DB2 Universal Database за OS/390 версия 5.1 не е база данни за управление на транзакции.

  2. Ако TM_DATABASE за транзакциите е DB2 Universal Database за OS/390 версия 5.1, тогава DB2 CS V2.1 базите данни, участващи в тази транзакция са разрешени САМО ЧЕТЕНЕ за клиентското приложение.

  3. Клиентските приложения за DB2 Universal Database Версия 7 могат да участват в разпределени единици работа с различни нива на сървъра на база данни, само ако DB2 Universal Database за OS/390 версия 5.1 е TM_DATABASE за транзакцията. За допълнителна информация се обърнете към съответната книга DB2 Connect: Бърз старт.

  4. Нивата на бази данни, поддържани за операциите с двуфазово записване през TCP/IP зависят от нивото на DB2 клиента, нивото на TM_DATABASE и нивата на участващите бази данни.

    Силно препоръчваме всички клиенти, които имат достъп до базите данни DB2 Universal Database Версия 7 и DB2 Universal Database за OS/390 версия 5 да са DB2 Universal Database Версия 7. DB2 версия 2.1 клиенти не могат да инициират транзакции с двуфазово записване, ако в транзакцията участват база данни DB2 Universal Database за OS/390 версия 5.

SQL оператори за хост или AS/400 сървър, поддържани от DB2 Connect

Следните оператори се компилират успешно за хост или AS/400 сървър, но не и за обработка върху DB2 Universal Database системи:

Тези оператори се поддържат и от процесор за обработка на команди.

Следните оператори се поддържат за обработка от хост или AS/400 сървър, но не са добавени към файла за свързване или пакета и не се поддържат от процесор за обработка на команди:

Предкомпилаторът извършва следните приемания:

SQL оператори за хост или AS/400 сървър, отхвърлени от DB2 Connect

Следните SQL оператори не се поддържат от DB2 Connect и не се поддържат от процесор за обработка на команди:

DB2 за VSE и VM допълнителните оператори от динамичния SQL се отхвърлят със SQLCODE -104 и синтактична грешка.


[ Начало на страницата | Предишна страница | Следваща страница ]