DB2 Connect gir et applikasjonsprogram tilgang til data i DB2-databaser på System/390- og AS/400-tjenere. En applikasjon som kjører på Windows, kan for eksempel få tilgang til data i en DB2 Universal Database for OS/390-database. Du kan opprette nye applikasjoner eller endre eksisterende applikasjoner som skal kjøre i et vertsmaskin- eller AS/400-miljø. Du kan også utvikle applikasjoner i et miljø og konvertere dem til et annet miljø.
Med DB2 Connect kan du bruke APIene nedenfor sammen med vertsdatabaseprodukter, for eksempel DB2 Universal Database for OS/390, så lenge vertsdatabaseproduktet støtter APIen:
Noen SQL-setninger er forskjellige i de ulike relasjonsdatabaseproduktene. Du kan støte på SQL-setninger som er
SQL-setninger i de to første kategoriene kan lett brukes i flere miljøer, men setningene i den tredje kategorien må endres først. Generelt sett kan ikke SQL-setninger i datadefinisjonsspråk (DDL) brukes i like mange miljøer som SQL-setningene i datahåndteringsspråk (DML).
DB2 Connect godtar noen SQL-setninger som DB2 Universal Database ikke støtter. DB2 Connect videresender disse setningene til verts- eller AS/400-tjeneren. Hvis du ønsker flere opplysninger om begrensningene på de ulike plattformene, for eksempel maksimal kolonnelengde, kan du slå opp i SQL Reference.
Hvis du flytter en CICS-applikasjon fra OS/390 eller VSE for å kjøre det under et annet CICS-produkt (for eksempel CICS for AIX), kan den også få tilgang til OS/390- eller VSE-databasen ved hjelp av DB2 Connect. Slå opp i håndboken CICS/6000 Application Programming Guide og CICS Customization and Operation hvis du ønsker flere opplysninger.
Når du programmerer i et vertsmaskin- eller AS/400-miljø, bør du vurdere disse faktorene:
DDL-setninger er forskjellige i de ulike IBM-databaseproduktene fordi lageret blir håndtert forskjellig på ulike systemer. På verts- eller AS/400-tjenere kan det være flere trinn fra du definerer en database til du utsteder en CREATE TABLE-setning. En serie med setninger kan for eksempel konvertere utformingen av logiske objekter til en fysisk fremstilling av disse objektene i lageret.
Forkompilatoren videresender mange slike DDL-setninger til verts- eller AS/400-tjeneren når du forkompilerer til en database på vertsmaskinen eller AS/400-tjeneren. De samme setningene blir ikke forkompilert mot en database på systemet der applikasjonen kjører. I en OS/2-applikasjon blir for eksempel CREATE STORGROUP-setningen forkompilert til en DB2 Universal Database for OS/390-database, men ikke til en DB2 for OS/2-database.
Generelt sett kan DML-setninger brukes i flere miljøer. SELECT-, INSERT-, UPDATE- og DELETE-setninger er like for alle IBMs relasjonsdatabaseprodukter. De fleste applikasjoner bruker primært DML SQL-setninger, som DB2 Connect støtter.
Når numeriske data blir overført til DB2 Universal Database, kan datatypen bli endret. SQLTYPE-verdier av typen numeriske data og sonede desimaldata (støttet av DB2 Universal Database for AS/400) blir konvertert til SQLTYPE-verdier av typen faste (pakkede) desimaldata.
Data med blandede byte kan bestå av tegn fra et tegnsett med utvidet UNIX-kode (EUC), et dobbeltbytetegnsett (DBCS) og et enkeltbytetegnsett (SBCS) i den samme kolonnen. På systemer som lagrer data i EBCDIC (OS/390, OS/400, VSE og VM), merker skiftut- og skiftinntegnene starten og slutten på dobbeltbytedata. På systemer som lagrer data i ASCII-format (for eksempel OS/2 og UNIX), er det ikke nødvendig med skiftinn- og skiftuttegn.
Hvis applikasjonen overfører data med blandede byte fra et ASCII-system til et EBCDIC-system, må du gi skifttegnene nok plass. Tilføy 2 byte til datalengden for hver konvertering fra SBCS- til DBCS-data. Hvis du ønsker kompatibilitet med flere miljøer, bør du bruke strenger med variabel lengde i applikasjoner som bruker data med blandede byte.
Lange felt (strenger som er lengre enn 254 tegn) blir behandlet forskjellig på ulike systemer. Det kan hende at en verts- eller AS/400-tjener bare støtter en undergruppe av skalarfunksjonene for lange felt. DB2 Universal Database for OS/390 støtter for eksempel bare funksjonene LENGTH og SUBSTR for lange felt. I tillegg kan en verts- eller AS/400-tjener ha ulik behandling av enkelte SQL-setninger. DB2 for VSE & VM har for eksempel begrensningen at INSERT-setningen bare kan bruke vertsvariabelen SQLDA eller verdien Null.
DB2 Connect støtter LOB-datatypen.
DB2 Connect støtter bare brukerdefinerte distinkte typer. Det støtter ikke abstrakte datatyper.
DB2 Connect behandler ROWID-datatypen som VARCHAR for bitdata.
DB2 Connect støtter heltall med åtte byte (64-biter). Den interne datatypen BIGINT gir støtte for kardinalitet av veldig store databaser, samtidig som datapresisjonen blir bevart.
De enkelte styresystemene for relasjonsdatabaser fra IBM har ulike grader for SQL-setningene GRANT og REVOKE. Slå opp i publikasjonene for de enkelte produktene for å kontrollere hvilken SQL-setning du bør bruke for de enkelte databasesystemene.
DB2 Connect støtter CONNECT TO- og CONNECT RESET-versjonen av CONNECT-setningen, samt CONNECT uten noen parametere. Hvis en applikasjon anroper en SQL-setning uten å utføre en eksplisitt CONNECT TO-setning først, blir det utført en implisitt tilkobling til standardapplikasjonstjeneren (hvis det er definert en).
Når du kobler deg til en database, blir informasjon som identifiserer styresystemet for relasjonsdatabasen, returnert i SQLERRP-feltet for SQLCA. Hvis applikasjonstjeneren er en IBM-relasjonsdatabase, inneholder de første tre bytene i SQLERRP en av disse verdiene:
Hvis du utsteder en CONNECT TO- eller null CONNECT-setning mens du bruker DB2 Connect, blir landkode- eller områdesymbolet i SQLERRMC-feltet for SQLCA returnert som blanktegn. IDen for kodet tegnsett (CCSID) for applikasjonstjeneren blir returnert i kodesettsymbolet.
Du kan eksplisitt frakoble ved hjelp av CONNECT RESET-setningen (for type 1 connect), RELEASE- og COMMIT-setningen (for type 2 connect) eller DISCONNECT-setningen (begge typene connect-setninger, men ikke i et TP-overvåkermiljø).
Hvis en tilkobling ikke blir eksplisitt frakoblet og applikasjonen avsluttes på en normal måte, iverksetter DB2 Connect resultatdataene implisitt.
Merk: | En applikasjon kan motta SQLCODE-verdier som angir feil, og likevel bli avsluttet på normal måte. I dette tilfellet iverksetter DB2 Connect dataene. Hvis du ikke vil at dataene skal iverksettes, må du utføre en ROLLBACK-kommando. |
Med FORCE-kommandoen kan du frakoble valgte brukere eller alle brukerne fra databasen. Databaser på verts- eller AS/400-tjenere har støtte for dette alternativet. Brukeren kan tvinges av DB2 Connect-arbeidsstasjonen.
Det er enkelte forskjeller i forkompilatorene blandt de ulike IBM-relasjonsdatabasesystemene. Forkompilatoren for DB2 Universal Database er forskjellig fra forkompilatoren til verts- eller AS/400-tjeneren på følgende måter:
DB2 Connect støtter bindingsalternativene for blokking for DB2-databasesystemet:
DB2 Connect bruker blokkstørrelsen som er definert i konfigurasjonsfilen for DB2-databasesystemet i RQRIOBLK-feltet. De gjeldende versjonene av DB2 Connect støtter blokkstørrelser opptil 32 767. Hvis det blir oppgitt større verdier i konfigurasjonsfilen for DB2-databasesystemet, bruker DB2 Connect verdien 32 767, men konfigurasjonsfilen for DB2-databasesystemet tilbakestilles ikke. Blokking blir håndtert på samme måte med den samme blokkstørrelsen for dynamisk og statisk SQL.
Merk: | De fleste vertssystemer eller AS/400-tjenere oppfatter dynamiske pekere som tvetydige, men DB2 Universal Database-systemer oppfatter noen dynamiske pekere som utvetydige. Hvis du vil unngå forvirring, kan du oppgi BLOCKING ALL med DB2 Connect. |
Oppgi blokkstørrelsen i konfigurasjonsfilen for DB2-databasesystemet ved hjelp av kommandolinjebehandleren (CLP), kontrollsenteret eller en API, som er beskrevet i Administrative API Reference og Command Reference.
En pakke har disse attributtene:
De enkelte vertssystemene eller AS/400-tjenerne har begrensninger på bruken av disse attributtene:
Merk: | DB2 Connect har støtte for kommandoen SET CURRENT PACKAGESET for DB2 Universal Database for OS/390 og DB2 Universal Database. |
CNULREQD-bindingsalternativet overstyrer behandlingen av strenger med avsluttende nulltegn som er oppgitt ved hjelp av LANGLEVEL-alternativet.
Hvis du vil vite hvordan strenger som er avsluttet med nulltegn, blir behandlet når de er klargjort ved at LANGLEVEL-alternativet er satt til MIA eller SAA1, leser du Application Development Guide.
Standardverdien er at CNULREQD er satt til Ja (YES). Dette fører til at strenger med avsluttende nulltegn blir tolket i henhold til MIA-standarder. Hvis du kobler deg til en DB2 Universal Database for OS/390-tjener, anbefaler vi på det sterkeste at du setter CNULREQD til Ja (YES). Du må binde applikasjoner som er kodet til SAA1-standarder (når det gjelder strenger med avsluttende nulltegn), med CNULREQD-alternativet satt til Nei (NO). Ellers blir strenger med avsluttende nulltegn tolket i henhold til MIA-standarder, selv om de blir klargjort ved at LANGLEVEL blir satt til SAA1.
Frittstående SQLCODE- og SQLSTATE-variabler, som er definert i ISO/ANS SQL92, støttes gjennom forkompileringsalternativet LANGLEVEL SQL92E. Det blir utstedt en SQL0020W-advarsel under forkompileringen, som angir at LANGLEVEL ikke er støttet. Denne advarselen gjelder bare funksjonene som står oppført under LANGLEVEL MIA i Command Reference, som er en undergruppe av LANGLEVEL SQL92E.
Forskjellene mellom EBCDIC og ASCII fører til forskjeller i sorteringsrekkefølgene i de ulike databaseproduktene, og de påvirker også ORDER BY- og GROUP BY-ledd. En måte å minimere disse forskjellene på, er ved å opprette en brukerdefinert rangfølge som etterlikner EBCDIC-sorteringsrekkefølgen. Du kan bare oppgi en rangfølge når du oppretter en ny database. Du finner flere opplysninger om dette i Application Development Guide, Administrative API Reference og Command Reference.
Merk: | Databasetabeller kan nå lagres i DB2 Universal Database for OS/390, i ASCII-format. Dette tillater hurtigere dataoverføring mellom DB2 Connect og DB2 Universal Database for OS/390, og fjerner behovet for feltprosedyrer, som ellers brukes til å konvertere data og endre rekkefølgen på dem. |
Ulike systemer håndterer referansebegrensninger på ulike måter:
Andre regler kan ha ulike nivåer av overlapping.
Måten databasetjeneren utfører låsing på, kan påvirke noen applikasjoner. Applikasjoner som bruker radnivålåsing, og isolasjonsnivået for pekerstabilitet kan for eksempel ikke uten videre brukes direkte på systemer som utfører sidenivålåsing. På grunn av disse underliggende forskjellene kan det hende at noen applikasjoner må justeres.
DB2 Universal Database for OS/390 og DB2 Universal Database kan tidsutkoble en lås og sende en returkode om feil til ventende applikasjoner.
De ulike relasjonsdatabaseproduktene til IBM gir ikke alltid samme SQLCODE-verdi for samme feil. Du kan løse dette problemet på to måter:
SQLSTATE-verdier har omtrent samme betydning i de ulike databaseproduktene, og produktene gir SQLSTATE-verdier som tilsvarer SQLCODE-verdiene.
Standardverdien er at DB2 Connect konverterer SQLCODE-verdier og symboler fra de ulike IBM-verts- eller AS/400-tjenerne til DB2 Universal Database-systemet du bruker. Du kan oppgi en egen SQLCODE-konverteringsfil hvis du vil overstyre standardkonverteringen, eller hvis du bruker en databasetjener som ikke har SQLCODE-konvertering (en ikke-IBM-databasetjener). Du kan også slå av SQLCODE-konvertering.
Du finner flere opplysninger i SQLCODE-konvertering.
Systemkatalogene kan variere i de ulike IBM-databaseproduktene. Mange forskjeller kan maskeres ved å bruke utsnitt. Du finner flere opplysninger om dette emnet i dokumentasjonen for databasetjeneren du bruker.
Katalogfunksjonene i CLI omgår dette problemet ved å ha støtte for den samme APIen og de samme resultatsettene for katalogspørringer i hele DB2-familien.
Det kan hende at de ulike IBM-relasjonsdatabaseproduktene behandler overflyt ved numerisk konvertering under hentetildelinger på forskjellige måter. Tenk deg at du skal hente en flytekolonne inn i en heltallsvertsvariabel fra DB2 Universal Database for OS/390 og fra DB2 Universal Database. Når du konverterer flytetallverdien til en heltallsverdi, kan det oppstå overflyt. Standardverdien er at DB2 Universal Database for OS/390 returnerer en SQLCODE-advarsel og en nullverdi til applikasjonen. DB2 Universal Database returnerer derimot en feil ved konverteringsoverflyt. Applikasjoner bør unngå overflyt ved numerisk konvertering under hentetildelinger ved å hente dataene inn i vertsvariabler med riktig størrelse.
DB2 Connect godtar disse isolasjonsnivåene når du klargjør eller binder en applikasjon:
Isolasjonsnivåene blir vist i rekkefølge fra mest beskyttelse til minst beskyttelse. Hvis verts- eller AS/400-tjeneren ikke støtter isolasjonsnivået du oppgir, blir det nest høyeste støttede nivået brukt.
I Tabell 2 ser du resultatene av hvert enkelt isolasjonsnivå på verts-
eller AS/400-applikasjonstjeneren.
DB2 Connect | DB2 Universal Database for OS/390 | DB2 for VSE & VM | DB2 Universal Database for AS/400 | DB2 Universal Database |
---|---|---|---|---|
RR | RR | RR | merknad 1 | RR |
RS | merknad 2 | RR | COMMIT(*ALL) | RS |
CS | CS | CS | COMMIT(*CS) | CS |
UR | merknad 3 | CS | COMMIT(*CHG) | UR |
NC | merknad 4 | merknad 5 | COMMIT(*NONE) | UR |
Merknader:
|
Med DB2 Universal Database for AS/400 kan du få tilgang til en ikke-journalført tabell hvis en applikasjon er bundet med isolasjonsnivået UR og blokking er satt til ALL, eller hvis isolasjonsnivået er NC.
Et klientprogram kan starte et tjenerprogram ved å utstede en SQL CALL-setning. Hver enkelt tjener fungerer litt forskjellig fra de andre tjenerne i dette tilfellet.
Alle CALL-setninger til DB2 for AS/400 fra REXX/SQL må bli dynamisk klargjort og utført av applikasjonen, som CALL-setningen som ble implementert i REXX/SQL-konverteringer til CALL USING DESCRIPTOR.
Hvis du vil vite mer om syntaksen til SQL CALL-setningen, leser du SQL Reference. Hvis du vil vite hvordan du bruker lagrede prosedyrer når du skriver applikasjonsprogrammer, leser du Application Development Guide.
Du kan starte tjenerprogrammet i DB2 Universal Database med den samme parameterkonvensjonen som tjenerprogrammene bruker i DB2 Universal Database for OS/390, DB2 Universal Database for AS/400 eller DB2 for VSE & VM. Hvis du vil vite mer om hvordan du starter lagrede prosedyrer for DB2 Universal Database, leser du Application Development Guide. Hvis du vil vite mer om parameterkonvensjonen på andre plattformer, leser du DB2-produktdokumentasjonen for plattformen.
Alle SQL-setningene i en lagret prosedyre blir utført som en del av SQL-arbeidsenheten som klient-SQL-programmet startet.
Innenfor DB2 Universal Database sender systemene alt du legger inn i indikatorvariablene. Når du bruker DB2 Connect, kan du imidlertid bare sende 0, -1 og -128 i indikatorvariablene.
Et tjenerprogram i DB2 Universal Database kan oppdatere SQLCA slik at det returnerer alle feil eller advarsler, men lagrede prosedyrer i DB2 Universal Database for OS/390 eller DB2 Universal Database for AS/400 har ikke denne støtten. Hvis du vil at den lagret prosedyren skal returnere en feilkode, må du sende den som en parameter. Tjeneren definerer bare SQLCODE og SQLCA for feil som er oppdaget på systemet.
DB2 Stored Procedure Builder har et brukervennlig miljø for å opprette, installere og teste lagrede prosedyrer. På denne måten kan du konsentrere deg om å opprette logikken for de lagrede prosedyrene dine i stedet for om detaljene ved å registrere, bygge og installere lagrede prosedyrer på en DB2-tjener. I tillegg kan du bruke Stored Procedure Builder til å utvikle lagrede prosedyrer på ett operativsystem og bygge dem på et annet tjeneroperativsystem.
Stored Procedure Builder er en grafisk applikasjon som støtter svært hurtig utvikling. Ved hjelp av Stored Procedure Builder kan du utføre disse oppgavene:
Du kan starte Stored Procedure Builder som en egen applikasjon fra programgruppen DB2 Universal Database, eller fra en disse utviklingsapplikasjonene:
Du kan også starte Stored Procedure Builder fra Kontrollsenter for DB2 for OS/390. Du kan starte Stored Procedure Builder som en egen prosess fra menyen Verktøy i Kontrollsenter, verktøylinjen eller mappen Lagrede prosedyrer. Fra vinduet Stored Procedure Builder kan du i tillegg eksportere en eller flere valgte lagrede SQL-prosedyrer som er bygd for en DB2 for OS/390-tjener, til en oppgitt fil som kan kjøre i Kommandolinjebehandler (CLP).
Stored Procedure Builder administrerer arbeidet ditt ved hjelp av Prosjekter. De enkelte Stored Procedure Builder-prosjektene lagrer tilkoblinger til bestemte databaser, for eksempel DB2 for OS/390-tjenere. I tillegg kan du opprette filtre for å vise undergrupper av de lagrede prosedyrene for de enkelte databasene. Når du åpner et nytt eller eksisterende Stored Procedure Builder-prosjekt, kan du bruke et filter på lagrede prosedyrer slik at du viser dem basert på navnet, skjemaet, språket eller samlings-IDen (bare for OS/390).
Det blir lagret tilkoblingsinformasjon i et Stored Procedure Builder-prosjekt, så når du åpner et eksisterende prosjekt, blir du automatisk bedt om å oppgi bruker-ID og passord for databasen. Ved hjelp av veiviseren Inserting SQL Stored Procedure kan du bygge lagrede SQL-prosedyrer på en DB2 for OS/390-tjener. For en lagret SQL-prosedyre som er bygd til en DB2 for OS/390-tjener, kan du definere alternativer for kompilering, forlink, link, binding, kjøretid, WLM-miljø og ekstern sikkerhet.
I tillegg kan du hente SQL-kostnadsinformasjon om den lagrede SQL-prosedyren, for eksempel informasjon om CPU-tid og annen DB2-kostnadsinformasjon om tråden som den lagrede SQL-prosedyren kjører på. Du kan i tillegg hente kostnadsinformasjon om ventetid ved låsekonflikt, antall hentesider, antall lese-I/Uer og antall skrive-I/Uer.
Kostnadsinformasjonen blir hentet ved at Stored Procedure Builder kobler seg til en DB2 for OS/390-tjener, utfører SQL-setningen og anroper en lagret prosedyre (DSNWSPM) for å finne ut hvor mye CPU-tid den lagrede SQL-prosedyren brukte.
Med sammensatt SQL kan du gruppere flere SQL-setninger i en enkelt utførbar blokk. Dette kan redusere nettverksbelastningen og forbedre svartiden.
DB2 Connect støtter ikke-enhetlig sammensatt SQL. Dette betyr at behandlingen av sammensatt SQL fortsetter selv om det oppstår en feil. (Med enhetlig sammensatt SQL, som ikke er støttet av DB2 Connect, tilbakestiller en feil hele gruppen med sammensatt SQL.)
Utføringen av setninger fortsetter helt til de blir avbrutt av applikasjonstjeneren. Generelt sett blir utføringen av den sammensatte SQL-setningen bare stoppet hvis det oppstår alvorlige feil.
Ikke-enhetlig sammensatt SQL kan brukes sammen med alle verts- eller AS/400-applikasjonstjenerne som er støttet.
Hvis det oppstår flere SQL-feil, blir SQLSTATE-verdiene for de sju første mislykkede setningene returnert i SQLERRMC-feltet for SQLCA med en melding om at det oppstod flere feil. Du finner flere opplysninger i SQL Reference.
Med DB2 Connect kan du utføre en flerstedsoppdatering, også kalt en tofaseiverksetting. En flerstedsoppdatering er en oppdatering av flere databaser i en enkelt distribuert arbeidsenhet (DUOW). Det er flere faktorer som avgjør om du kan bruke denne funksjonen:
Dette gjelder interne DB2 UDB-applikasjoner og applikasjoner som er koordinert av en ekstern transaksjonsovervåker, for eksempel IBM TXSeries, CICS for Open Systems, BEA Tuxedo, Encina Monitor og Microsoft Transaction Server.
Merk: | Du finner flere opplysninger om BEA Tuxedo i Bruke DB2 Connect sammen med transaksjonsovervåkere.Du finner flere opplysninger om XA-konsentratoren i DB2 Connect-tilkoblingskonsentrator. |
Hvis både interne DB2-applikasjoner og TP-overvåkerapplikasjoner bruker en vanlig DB2 Connect Enterprise Edition-tjener til å få tilgang til vertsmaskindata gjennom TCP/IP-tilkoblinger, må synkroniseringspunktstyreren brukes.
Hvis en enkelt DB2 Connect Enterprise Edition-tjener blir brukt til å få tilgang til vertsdata ved hjelp av både SNA- og TCP/IP-nettverksprotokoller og tofaseiverksetting er nødvendig, må synkroniseringspunktstyreren brukes. Dette gjelder både DB2-applikasjoner og TP-overvåkerapplikasjoner.
Disse setningene blir kompilert under behandling på verts- eller AS/400-tjenere, men ikke på DB2 Universal Database-systemer:
Kommandolinjebehandleren har også støtte for disse setningene.
Disse setningene er støttet for behandling på verts- eller AS/400-tjenere, men de blir ikke føyd til bindingsfilen eller pakken, og de er ikke støttet av kommandolinjebehandleren:
Forkompilatoren går ut fra følgende:
Disse SQL-setningene er ikke støttet av DB2 Connect og ikke støttet av kommandolinjebehandleren:
Utvidede dynamiske SQL-setninger for DB2 for VSE & VM blir avvist med -104 og SQLCODE-koder for syntaksfeil.