Vha. DB2 Connect kan en applikation få adgang til data i DB2-databaser på System/390- og AS/400-servere. En applikation under Windows kan f.eks. få adgang til data i en DB2 Universal Database til OS/390-database. Du kan udvikle nye applikationer eller ændre eksisterende applikationer, så de kan udføres i et værts- eller AS/400-miljø. Du kan også udvikle applikationer i ét miljø og flytte dem til et andet.
DB2 Connect giver dig mulighed for at benytte følgende API'er sammen med værtsdatabaseprodukter som f.eks. DB2 Universal Database til OS/390, så længe elementet understøttes af værtsdatabaseproduktet:
Nogle SQL-sætninger kan være forskellige i forskellige relationsdatabaseprodukter. SQL-sætninger kan:
SQL-sætninger i de to første kategorier kan uden større problemer flyttes til andre platforme, mens tredje kategori først skal ændres. Generelt er SQL-sætninger i DDL-format (Data Definition Language) ikke så flytbare som dem i DML-format (Data Manipulation Language).
DB2 Connect accepterer visse SQL-sætninger, der ikke understøttes af DB2 Universal Database. DB2 Connect overfører disse sætninger til værts- eller AS/400-serveren. Der er flere oplysninger i SQL Reference om begrænsningerne på forskellige platforme, f.eks. maksimal kolonnelængde.
Hvis du flytter en CICS-applikation fra OS/390 eller VSE til et andet CICS-produkt (f.eks. CICS til AIX), kan den også få adgang til OS/390- og VSE-databasen vha. DB2 Connect. Der er flere oplysninger i CICS/6000 Application Programming Guide og CICS Customization and Operation.
Når du programmerer i et værts- eller AS/400-miljø, skal følgende faktorer overvejes:
DDL-sætninger afviger i IBM's databaseprodukter, fordi lagerplads håndteres forskelligt på forskellige systemer. På værts- eller AS/400-serversystemer kan der være flere trin fra design af en database til afsendelse af en CREATE TABLE-sætning. En række sætninger kan f.eks. omsætte design af logiske objekter til den fysiske repræsentation af disse objekter i lageret.
Præ-compileren overfører mange af disse DDL-sætninger til værts- eller AS/400-serveren, når du prækompilerer mod en værts- eller AS/400-serverdatabase. Det ville ikke være muligt at prækompilere de samme sætninger mod en database på det system, hvor applikationen udføres. I en OS/2-applikation kan CREATE STOGROUP-sætningen f.eks. blive prækompileret uden fejl mod en DB2 Universal Database til OS/390-database, men ikke mod en DB2 til OS/2-database.
Der er generelt få problemer med at flytte DML-sætninger til andre platforme. SELECT-, INSERT-, UPDATE- og DELETE-sætninger ligner hinanden i IBM's relationsdatabaseprodukter. De fleste applikationer benytter primært DML SQL-sætninger, som understøttes af DB2 Connect-programmet.
Når numeriske data overføres til DB2 Universal Database, kan datatypen blive ændret. Numeriske og zonede decimaltals SQLTYPEr (der understøttes af DB2 Universal Database til AS/400) konverteres til faste (pakkede) decimaltals SQLTYPEr.
Disse data kan bestå af tegn fra det udvidede UNIX-tegnsæt (EUC), et dobbeltbytetegnsæt (DBCS) og et enkeltbytetegnsæt (SBCS) i samme kolonne. I systemer, hvor data gemmes i EBCDIC-format (OS/390, OS/400, VSE og VM), markerer SOSI-koder (Shift-Out/Shift-In) begyndelsen og afslutningen af dobbeltbytedata. I systemer, hvor data gemmes i ASCII-format (f.eks. OS/2 og UNIX), kræves ikke SOSI-koder.
Hvis en applikation overfører data med både enkelt- og dobbeltbytetegn fra et ASCII-system til et EBCDIC-system, skal du sikre, at der er tilstrækkelig plads til SOSI-koderne. For hvert skift fra SBCS- til DBCS-data skal der lægges 2 byte til datalængden. Der opnås højere flytbarhed, hvis der benyttes strenge med variabel længde i applikationer med en blanding af enkelt- og dobbeltbytetegn.
Lange felter (strenge på over 254 tegn) håndteres forskelligt på forskellige systemer. En værts- eller AS/400-server understøtter måske kun en del af skalarfunktionerne for lange felter. DB2 til MVS/ESA tillader f.eks. kun funktionerne LENGTH og SUBSTR for lange felter. En værts- eller AS/400-server kan også håndtere bestemte SQL-sætninger forskelligt. DB2 til VSE og VM kræver f.eks., at der i en INSERT-sætning kun benyttes en værtsvariabel, SQLDA eller en NULL-værdi.
LOB-datatypen understøttes af DB2 Connect.
Kun brugerdefinerede DISTINCT-typer understøttes af DB2 Connect. Abstrakte datatyper understøttes ikke.
ROWID-datatypen håndteres af DB2 Connect som VARCHAR for bit-data.
Heltal på 8 byte (64-bit) understøttes af DB2 Connect. Den interne BIGINT-datatype bruges til at understøtte kardinaliteten i meget store databaser, samtidigt med at datapræcisionen bevares.
SQL-sætningerne GRANT og REVOKE kan angives på forskellige niveauer i de enkelte IBM-relationsdatabasesystemer. Den korrekte SQL-syntaks kan ses i dokumentationen til det relevante databasesystem.
I DB2 Connect kan følgende udgaver af CONNECT-sætningen benyttes: CONNECT TO, CONNECT RESET og CONNECT uden parametre. Hvis en applikation afsender en SQL-sætning uden først at afsende en eksplicit CONNECT TO-sætning, oprettes automatisk forbindelse til standardapplikationsserveren (hvis der er en).
Når der oprettes forbindelse til en database, returneres oplysninger om relationsdatabasesystemet i SQLERRP-feltet i SQLCA. Hvis applikationsserveren er en IBM-relationsdatabase, er de første 3 byte i SQLERRP en af følgende strenge:
Hvis der afsendes en CONNECT TO-sætning eller en CONNECT-sætning uden parametre, når DB2 Connect benyttes, returneres blanktegn i SQLERRMC-feltets plads til landekode eller sprogområde i SQLCA. Applikationsserverens CCSID returneres på pladsen til tegntabel.
En forbindelse kan eksplicit afbrydes vha. CONNECT RESET (ved Type 1-forbindelser), RELEASE og COMMIT (ved Type 2-forbindelser) eller DISCONNECT (begge forbindelsestyper men ikke i et transaktionsovervågningsmiljø).
Hvis en forbindelse ikke afbrydes eksplicit, og applikationen afsluttes normalt, udfører DB2 Connect implicit commit af data.
Bemærk: | En applikation kan modtage SQLCODE-værdier, der indikerer fejl, og alligevel blive afsluttet normalt. I det tilfælde udfører DB2 Connect commit af data. Hvis du ikke vil have, at der udføres commit af data, skal du afsende en ROLLBACK-kommando. |
Vha. FORCE-kommandoen kan du lukke forbindelsen til databasen for bestemte brugere eller alle brugere. Det understøttes for værts- eller AS/400-serverdatabaser. Brugerens forbindelse til DB2 Connect-arbejdsstationen kan lukkes.
Præ-compilerne til de forskellige IBM-relationsdatabasesystemer afviger fra hinanden. Præ-compileren til DB2 Universal Database afviger fra præ-compilerne til værts- eller AS/400-servere på følgende måder:
DB2 Connect understøtter blokningsbindeparametrene i DB2-databasesystemet:
DB2 Connect-programmet bruger den blokstørrelse, der er defineret i konfigurationsfilen til DB2-databasesystemet til RQRIOBLK-feltet. De aktuelle værts- eller AS/400-versioner understøtter blokstørrelser på op til 32767. Hvis der er angivet en større værdi i konfigurationsfilen til DB2-databasesystemet, bruger DB2 Connect værdien 32767, men værdien i konfigurationsfilen ændres ikke. Blokning håndteres på samme måde og med samme blokstørrelse for dynamisk og statisk SQL.
Bemærk: | De fleste værts- eller AS/400-serversystemer betragter dynamiske cursorer som flertydige, men DB2 Universal Database-systemer opfatter visse dynamiske cursorer som entydige. Med DB2 Connect kan du angive BLOCKING ALL for at undgå forvirring. |
Du kan angive blokstørrelsen i konfigurationsfilen til DB2-databasesystemet vha. DB2-kommandolinien, DB2 Kontrolcenter eller et API, som beskrevet i Administrative API Reference og Command Reference.
En pakke har følgende egenskaber:
Der er begrænsninger i brugen af disse egenskaber for hvert værts- eller AS/400-serversystem:
Bemærk: | DB2 Connect understøtter kommandoen SET CURRENT PACKAGESET til DB2 Universal Database til OS/390 og DB2 Universal Database. |
Bindeparameteren CNULREQD erstatter håndteringen af strenge afsluttet med NULL, der angives vha. parameteren LANGLEVEL.
Application Development Guide indeholder en beskrivelse af, hvordan NULL-afsluttede strenge håndteres, når de klargøres med værdien MIA eller SAA1.
Standardværdien for CNULREQD er YES. Den bevirker, at NULL-afsluttede strenge fortolkes i overensstemmelse med MIA-standarden. Hvis der oprettes forbindelse til en DB2 Universal Database til OS/390-server, anbefales det kraftigt at sætte CNULREQD til YES. Applikationer, der er kodet efter SAA1-standarden (med hensyn til NULL-afsluttede strenge), skal bindes med værdien NO for CNULREQD-parameteren. Ellers fortolkes NULL-afsluttede strenge i overensstemmelse med MIA-standarden, selv om strengene er klargjort med værdien SAA1 for LANGLEVEL-parameteren.
Enkeltstående SQLCODE- og SQLSTATE-værdier, der er defineret i ISO/ANS SQL92, understøttes vha. prækompileringsparameteren LANGLEVEL SQL92E. På prækompileringstidspunktet afsendes en SQL0020W-advarsel, der angiver at LANGLEVEL ikke understøttes. Advarslen gælder kun de elementer, der er opstillet under LANGLEVEL MIA i Command Reference, som er et udsnit af LANGLEVEL SQL92E.
Forskellene mellem EBCDIC og ASCII medfører afvigelser i sorteringsrækkefølgen i forskellige databaseprodukter og har også indflydelse på udtrykkene ORDER BY og GROUP BY. Du kan minimere forskellene ved at oprette din egen sorteringsrækkefølge, der efterligner EBCDIC-sorteringsrækkefølgen. Sorteringsrækkefølgen kan kun angives, når der oprettes en ny database. Der er flere oplysninger i Application Development Guide, Administrative API Reference og Command Reference.
Bemærk: | Databasetabeller kan nu gemmes i ASCII-format i DB2 Universal Database til OS/390. Det medfører hurtigere dataoverførsel mellem DB2 Connect og DB2 Universal Database til OS/390 og fjerner behovet for at oprette feltprocedurer til konvertering af data og ændring af rækkefølgen. |
Referencebetingelser håndteres forskelligt af forskellige systemer:
Reglerne vedrørende kædesletning varierer også.
Den måde, databaseserveren udfører låsning på, kan have indflydelse på visse applikationer. Applikationer, der er udviklet, så der benyttes låsning på rækkeniveau og isolationsniveauet cursorstabilitet, kan ikke umiddelbart flyttes til systemer, der udfører låsning på sideniveau. På grund af disse indbyggede forskelle kan det være nødvendigt at justere applikationer.
I DB2 Universal Database til OS/390- og DB2 Universal Database-programmet er det muligt at sætte en tidsfrist på en lås og sende en fejlreturkode til ventende applikationer.
Der sendes ikke i alle tilfælde samme SQLCODE-værdi for tilsvarende fejl fra de forskellige IBM-relationsdatabaseprodukter. Du kan håndtere problemet på to måder:
SQLSTATE-værdier har stort set samme betydning i databaseprodukterne, og produkterne afsender SQLSTATE-værdier, der svarer til SQLCODE-værdierne.
Som standard konverterer DB2 SQLCODE-værdier og -felter fra hvert IBM værts- eller AS/400-serversystem til dit DB2 Universal Database-system. Du kan angive din egen fil til konvertering af SQLCODE-værdier, hvis du vil erstatte standardkonverteringen, eller hvis du bruger en databaseserver, der ikke konverterer SQLCODE-værdier (en ikke-IBM-databaseserver). Du kan også deaktivere SQLCODE-konvertering.
Der er flere oplysninger under Konvertering af SQLCODE-værdier.
Systemkatalogerne er forskellige i IBM-databaseprodukterne. Mange forskelle kan maskeres ved hjælp af udpluk (views). Du kan finde oplysninger i dokumentationen til den databaseserver, du bruger.
Katalogiseringsfunktionerne i CLI løser problemet ved at understøtte samme API og resultatsæt for katalogforespørgsler i hele DB2-familien.
Når numeriske tal hentes fra databasen og konverteres inden tildeling til en variabel, kan der forekomme overløb. Overløb kan blive håndteret forskelligt af forskellige IBM-relationsdatabaseprodukter. Eksempel: En kolonne af typen Float hentes ind i en værtsvariabel af typen Integer fra DB2 Universal Database til OS/390 og fra DB2 Universal Database. Når Float-værdien konverteres til et heltal, kan der opstå overløb. DB2 Universal Database til OS/390 afsender som standard en advarsels-SQLCODE og en NULL-værdi til applikationen. Derimod returnerer DB2 Universal Database en fejl for konverteringsoverløb. Det anbefales, at du undgår overløb ved numeriske konverteringer ved at hente data ind i værtsvariabler af passende størrelse.
DB2 Connect accepterer følgende isolationsniveauer, når der udføres BIND eller PREP af en applikation:
Isolationsniveauerne er opstillet fra den største til den mindste beskyttelse. Hvis værts- eller AS/400-serveren ikke understøtter det angivne isolationsniveau, benyttes det næste niveau.
I Tabel 2 vises resultatet af hvert isolationsniveau på de enkelte
værts- eller AS/400-applikationsservere.
DB2 Connect | DB2 Universal Database til OS/390 | DB2 til VSE og VM | DB2 Universal Database til AS/400 | DB2 Universal Database |
---|---|---|---|---|
RR | RR | RR | Bemærkning 1 | RR |
RS | Bemærkning 2 | RR | COMMIT(*ALL) | RS |
CS | CS | CS | COMMIT(*CS) | CS |
UR | Bemærkning 3 | CS | COMMIT(*CHG) | UR |
NC | Bemærkning 4 | Bemærkning 5 | COMMIT(*NONE) | UR |
Bemærkninger:
|
I DB2 Universal Database til AS/400 kan du få adgang til en ikke-journaliseret tabel, hvis en applikation bindes med isolationsniveau UR og BLOCKING=ALL, eller hvis isolationsniveauet sættes til NC.
Et klientprogram kan starte et serverprogram ved at sende en SQL CALL-sætning. I det tilfælde fungerer de enkelte servere lidt forskelligt.
Alle CALL-sætninger fra REXX/SQL til DB2 til AS/400 skal klargøres (PREP) og udføres dynamisk af applikationen, da den CALL-sætning, der er implementeret i REXX/SQL, omsættes til CALL USING DESCRIPTOR.
Syntaksen for SQL CALL-sætningen er beskrevet i SQL Reference. Der er flere oplysninger om, hvordan lagrede procedurer kan anvendes, når man skriver applikationprogrammer, i Application Development Guide.
Du kan starte serverprogrammet på DB2 Universal Database vha. samme parametersyntaks, som benyttes af serverprogrammer på DB2 Universal Database til OS/390, DB2 Universal Database til AS/400 eller DB2 til VSE og VM. I Application Development Guide er der flere oplysninger om kald af lagrede procedurer i DB2 Universal Database. DB2-dokumentationen til andre platforme indeholder flere oplysninger om parametersyntaks.
Alle SQL-sætninger i en lagret procedure udføres som en del af den SQL-unit of work, der er startet af SQL-klientprogrammet.
Mellem systemer med DB2 Universal Database overføres det, der placeres i indikatorvariablerne. Når du bruger DB2 Connect, kan du kun overføre 0, -1 og -128 i indikatorvariablerne.
Et serverprogram på DB2 Universal Database kan opdatere SQLCA med en fejl eller advarsel, der skal returneres, men der er ikke samme mulighed i DB2 Universal Database til OS/390 eller DB2 Universal Database til AS/400. Hvis der skal returneres en fejlkode fra den lagrede procedure, skal den overføres som en parameter. Serveren opdaterer kun SQLCODE og SQLCA i tilfælde af systemregistrerede fejl.
DB2 Stored Procedure Builder er et brugervenligt program, der anvendes til at udvikle, installere og afprøve lagrede procedurer. Med dette program kan du fokusere på udvikling af logikken til lagrede procedurer i stedet for detaljerne vedrørende registrering, bygning og installation af lagrede procedurer på en DB2-server. Du kan desuden anvende programmet til at udvikle lagrede procedurer på ét styresystem og bygge dem på andre serverstyresystemer.
Stored Procedure Builder er en grafisk applikation med lynhurtige funktioner til udvikling. Du kan anvende programmet til at udføre følgende opgaver:
Du kan starte Stored Procedure Builder som en separat applikation fra DB2 Universal Database-programgruppen, eller du kan starte programmet fra et af følgende udviklingsværktøjer:
Du kan desuden starte Stored Procedure Builder fra kontrolcentret i DB2 til OS/390. Du kan starte programmet som en separat proces fra menuen Værktøjer i kontrolcentret, værktøjslinien eller folderen Lagrede procedurer. Fra projektvinduet for lagrede procedurer kan du endvidere eksportere én eller flere valgte lagrede SQL-procedurer, der er bygget til en DB2 til OS/390-server i en bestemt fil, der kan udføres fra DB2-kommandolinien.
Stored Procedure Builder håndterer dine arbejdsdata vha. projekter. For hvert projekt i Stored Procedure Builder gemmes dine forbindelser til bestemte databaser, f.eks. DB2 til OS/390-servere. Du kan også oprette filtre til at få vist status for de lagrede procedurer for hver enkelt database. Når du åbner et nyt eller eksisterende projekt i Stored Procedure Builder, kan du filtrere de lagrede procedurer, så du får dem vist ud fra enten navn, skema, sprog eller gruppe-id (kun OS/390).
Oplysninger om forbindelser gemmes i et Stored Procedure Builder-projekt. Når du åbner et eksisterende projekt, bliver du derfor automatisk bedt om at angive bruger-id og kodeord til databasen. Hvis du anvender guiden til indsættelse af lagrede SQL-procedurer, kan du bygge lagrede SQL-procedurer på en DB2 til OS/390-server. For en lagret SQL-procedure, der er bygget til en DB2 til OS/390-server, kan du angive værdier for parametrene COMPILE, PRELINK, LINK, BIND, RUNTIME og for WLM-miljø samt for eksterne sikkerhedsparametre.
Desuden kan du få oplysninger om SQL-omkostninger, herunder oplysninger om CPU-tid og andre DB2-omkostninger, for den programdel (thread), hvor den lagrede SQL-procedure udføres. Du kan specielt få oplysninger om omkostninger vedrørende ventetid ved låsekonflikter, GETPAGE-antallet samt antallet af I/O-læse- og -skriveaktiviteter.
Hvis du vil have oplysninger om omkostninger, opretter Stored Procedure Builder forbindelse til en DB2 til OS/390-server, udfører SQL-sætningen og kalder en lagret procedure (DSNWSPM) for at finde ud af, hvor meget CPU-tid den lagrede SQL-procedure har anvendt.
Vha. sammensat SQL kan flere SQL-sætninger grupperes, så de kan udføres samlet. Det kan reducere netværkstiden og forbedre svartiden.
DB2 Connect understøtter NOT ATOMIC sammensat SQL. Det betyder, at behandlingen af sammensat SQL fortsætter efter en fejl. Ved ATOMIC sammensat SQL, som ikke understøttes af DB2 Connect, ville en fejl medføre rollback af hele den sammensatte SQL-gruppe.
Udførelsen af sætninger fortsætter, indtil de stoppes af applikationsserveren. Normalt stoppes udførelsen af sammensat SQL kun i tilfælde af alvorlige fejl.
NOT ATOMIC sammensat SQL kan bruges sammen med alle de understøttede værts- eller AS/400-applikationsservere.
Hvis der opstår flere SQL-fejl, returneres SQLSTATE-værdierne for de første syv sætninger med fejl i SQLERRMC-feltet i SQLCA sammen med en meddelelse om, at der er opstået flere fejl. Der er flere oplysninger i SQL Reference.
DB2 Connect gør det muligt at udføre en multiopdatering, også kaldet en tofase-commit. Ved en multiopdatering opdateres flere databaser inden for en enkelt distribueret unit of work (DUOW). Hvorvidt du kan anvende denne funktion, afhænger af flere faktorer:
Ovenstående gælder for rene DB2 UDB-applikationer og applikationer, der koordineres vha. eksterne transaktionsovervågningsprogrammer som IBM TXSeries, CICS for Open Systems, Encina Monitor og Microsoft Transaction Server.
Bemærk: | Der er flere oplysninger om BEA Tuxedo i Brug af DB2 Connect sammen med transaktionsovervågning. Der er flere oplysninger om XA-koncentratoren i DB2 Connect-forbindelseskoncentrator. |
Hvis både rene DB2-applikationer og transaktionsovervågede applikationer benytter en DB2 Connect Enterprise Edition-server til at få adgang til data på værtssystemer via TCP/IP-forbindelser, skal du bruge SPM (Sync Point Manager).
Hvis en enkelt DB2 Connect Enterprise Edition-server skal benyttes til at få adgang til data på værtssystemer via både SNA- og TCP/IP-protokoller, og der kræves tofase-commit, skal du anvende SPM (Sync Point Manager). Det gælder både DB2-applikationer og transaktionsovervågede applikationer.
Følgende sætninger kompileres uden fejl til behandling på værts- eller AS/400-servere men ikke til behandling på DB2 Universal Database-systemer:
Sætningerne understøttes også af DB2-kommandolinien.
Følgende sætninger understøttes også til behandling på værts- eller AS/400-servere, men føjes ikke til bindefilen eller pakken og understøttes ikke af DB2-kommandolinien:
Præ-compileren antager følgende:
Følgende SQL-sætninger understøttes hverken af DB2 Connect eller af DB2-kommandolinien:
Udvidede dynamiske SQL-sætninger fra DB2 til VSE og VM afvises med SQLCODE -104 og syntaksfejl.