DUP Brukerhåndbok

 

 

 

Database Update Pilot
 
Brukerhåndbok

 

Versjon 0.19 - 09.04.2002

 

1 Introduksjon

1.1 Hva er Database Update Pilot (DUP)?

DUP er et verktøysett for utforming og distribusjon av databaseoppgraderinger. Systemleverandøren bruker DUP Designer til å lage DUP-filer som sendes til kundene. Kundene kjører DUP-filene mot sin database med DUP Processor.

DUP-filene erstatter skriptfiler, og gir i tillegg versjonskontroll og robust feilhåndtering.

Versjonskontrollen lenker sammen DUP-filene i kjeder. 

Det er umulig å kjøre filene i feil rekkefølge. 

Feilhåndteringen sørger for at eventuelle feil lagres  i DUP-filen, og kan inspiseres senere.

For kundene innebærer DUP helautomatisert oppgradering med ett verktøy. Det kreves ingen kunnskaper om databaser for å kjøre DUP-filer, og det er er svært lav risiko for at det oppstår feil. Vi har erfart at kunder kan klare seg i årevis helt uten databasekompetent personell fordi sluttbruker selv foretar oppgraderinger med DUP.

For systemleverandøren innebærer DUP kontroll over databasene. Man vet hvilke databaseobjekter kundene har, og ved å ta i bruk DUP vil man også spare tid på brukerstøtte og feilretting fordi installasjonen hos kundene er automatisert. 

Oppgraderinger er en nødvendighet for alle systemleverandører, og det er viktig å utvikle og følge rutiner som sikrer kvaliteten ved oppgradering. Siden slikt arbeid ikke tilhører bedriftenes kjernevirksomhet, tilbys DUP for å automatisere kvalitetssikringen. Spart tid og frustrasjon kan rettes inn mot viktigere arbeidsoppgaver innen kjernevirksomheten.

1.2 Hvem har bruk for DUP?

DUP er et nyttig verktøy for alle systemleverandører som ønsker kvalitetssikring av sine oppgraderingsrutiner for databaser. Spesielt nyttig er DUP hvis ett eller flere av følgende kriterier også gjelder:

1.3 Introduksjonseksempel 

Du arbeider med utvikling av en database med personopplysninger, og i forrige distribusjon – versjon 1.0.0.2 – la du til en 20-tegns kolonne email i tabellen Person.

Det viser seg nå at kolonnen er for liten, og du vil lage en ny versjon 1.0.0.3 hvor feltlengden på email-kolonnen økes til 100 tegn.

Du lager en DUP-fil med følgende 4 uttrykk:

Du lagrer filen med navnet 1003.DUP, og distribuerer den til kundene.

Noen kunder har kanskje ikke kjørt forrige DUP-fil, og har dermed ikke email-kolonnen på plass i databasen. Endring av feltlengde på en kolonne som ikke finnes, ville generert en feil som kan skape støy og behov for brukerstøtte. Med DUP unngår du dette problemet. Versjonskontrollen tillater ikke kjøring av 1.0.0.3 før 1.0.0.2. 

1.4 Oversikt over DUP-verktøyene

DUP Designer (Dup.exe) er systemutviklerens verktøy. Den brukes til å lage DUP-filene med pålogging, versjonskontroll og ett eller flere uttrykk (statements) som utfører databaseendringer, legger inn data, etc. Hvert uttrykk gis en tittel som beskriver hva endringen går ut på.

DUP Windows Processor (DupWin.exe) er kundens verktøy, og brukes kun til å kjøre DUP-filer. Kunden logger på, og kan se tittelen på hvert uttrykk som kjøres. Resultatet av kjøringen er enten vellykket eller mislykket. Etter en mislykket kjøring kan kunden returnere DUP-filen. Systemutvikler kan åpne filen og lese feilmeldinger og andre detaljer om kjøringen.

DUP Console Processor (DupConsole.exe) er kommandolinjeversjonen av DUP Processor, og kan brukes til å kjøre flere DUP-filer i en sats. 

1.5 Systemkrav

1.5.1 Verktøyene

Verktøyene DUP Designer, DUP Windows Processor og DUP Console Processor har de samme systemkrav:

Operativsystem: Microsoft Windows NT 4, Microsoft Windows 2000, Microsoft Windows XP

RAM: Bruker opptil 10 MB RAM

1.5.2 Databasesystemer DBMS som støttes

ORACLE 7.3.4, ORACLE 8, ORACLE 8i og ORACLE 9i

Flere systemer vil støttes etter hvert.

2 Begreper

2.1 MBS Oppdateringsmodell

Et grunnleggende prinsipp for utviklingen av DUP, er ønsket om at alle objekter skal være identiske i alle databaser som har samme versjonsnummer. Hvis du vet hvilken versjon av databasen en kunde har, skal du kunne vite nøyaktig hvilke tabeller, kolonner, views, triggere, prosedyrer, funksjoner, etc. som finnes i basen hans. Det er også ønskelig at systemdefinerte data som skal være identiske i alle baser med samme versjon.

Dette kravet innfris ved hjelp av vår oppgraderingsmodell MBS - Master Baseline Syncronization. Modellen består av et sett DUP-filer, et sett databaseinstanser og noen retningslinjer for bruk. Hovedprinsippet er at leverandøren har en database - Masterdatabasen - som ikke brukes til annet enn å være mal for alle andre databaser.  

2.1.1 MBS DUP-filer

Fil Antall Formål Retningslinjer for bruk
Utviklingsdup 1 Utvikling av ny modulversjon. Det skal finnes kun 1 slik fil. Hvis flere utviklere jobber med endringer i samme databasemodul, må filen underlegges låsekontroll slik at kun én utvikler kan jobbe på den om gangen.

Filen mangler (eller har disablet) uttrykk som oppdaterer versjonsnummer, og kan dermed kjøres flere ganger. 

Hver gang en utvikler har satt inn uttrykk, skal filen kjøres mot testbasen uten å tilbakestille filen verken før eller etter kjøringen. 

Filen kan gjerne hete <modulnavn>_XXXX.dup for å indikere at versjonsnummer ikke er satt ennå, f. eks. ACCOUNTING_XXXX.dup.

Oppgraderingsdup En for hver
publiserte modulversjon
Distribusjon av nye versjoner. For hver baselining publiseres en DUP-fil med oppgraderinger som inngår i den nye versjonen av modulen. 

Filene bør hete <modulnavn>_<versjonsnummer>.dup, f. eks. ACCOUNTING_2101.dup.

 

2.1.2 MBS Databaseinstanser

Databaseinstans Antall Formål Retningslinjer for bruk
Utviklingsdatabase 1 eller flere Utvikling av ny modulversjon Ingen restriksjoner. Eksperimentering og direkte kjøring av oppgraderingskommandoer (DDL) er tillatt.
Testdatabase 1 Testing Oppdateres kun ved kjøring av Utviklingsdupen. Mellom baseliningene kjøres filen uten versjonsoppdatering. Ved baseline kjøres versjonsoppdatering, og Utviklingsdupen gjøres om til en publisert Oppgraderingsdup
Masterdatabase 1 Original for installasjoner Oppdateres kun ved kjøring av komplett Oppgraderingsdup etter baselining.
Produksjonsdatabase Flere Produksjon Oppdateres kun ved kjøring av tilsendte Oppgraderingsduper.

Masterdatabasen hos leverandøren inneholder til enhver tid den siste distribuerte versjonen av databasen. Tabellene er tomme bortsett fra systemdefinerte data. Ved installasjon hos en ny kunde kan man dermed importere en kopi av master. 

Restriksjonene på oppdatering er laget for å sikre at Master og Produksjonsbaser forblir identiske. Merk at det er kun mot utviklingsbase(r) man kan kjøre DDL eller DML direkte. Alle de andre databasene kan man kun oppdatere indirekte gjennom å kjøre DUP-filer.

2.1.3 Data i MBS-modellen

DUP datauttrykk er fleksible, og brukes i stor utstrekning til å distribuere alle slags data til kunder. For oppgraderings-duper er det imidlertid restriksjoner.

Type data Eksempel Retningslinjer for bruk
Systemdefinerte, statiske data som skal være like i alle instanser Koder, metadata Systemdefinerte data er en del av systemet, og bør være på plass etter nyinstallasjoner. Slike data hører derfor naturlig hjemme i oppgraderingsduper.
Kundeavhengige, statiske data Kunde-ID, lisensnummer Kan lagres ved hjelp av en Utviklingsdup med et parameteruttykk som spør installatør etter kode. 
Kundeavhengige, dynamiske data (produksjonsdata)   Skal ikke forekomme i oppgraderingsduper

2.1.4 MBS Baselining

Baselining innebærer at en ny versjon av en databasemodul blir klar for publisering. 

Utviklingsdupen er endret en eller flere ganger siden forrige baselining. Hvert uttrykk er kjørt fortløpende mot testbasen, og ikke mot andre baser. Utviklingsdupen er ikke tilbakestilt, og dermed består filen av en serie kjørte uttrykk samt et disablet versjonsoppdateringsuttrykk til slutt. 

Baselining er nå gjennomført.

2.1.5 Eksempel på hvordan MBS-modellen sikrer synkrone baser over tid

I eksemplet har man i tillegg til Masterdatabasen en eldre og en helt ny installasjon ute hos kunder. Alle basene er likevel identiske hva databaseobjekter angår. 

Tidspunkt
0)
 
1)
 
 
2)
 
Masterdatabase
Bygging
Dup 1
Dup 2
Dup 3
Dup 4
Dup 5
 
Kundedatabase 1
 
 
Installasjon
Dup 3
Dup 4
Dup 5
 
Kundedatabase 2
 
 
 
 
 
Installasjon

Tidspunkt 0) Masterdatabasen ble bygd
Tidspunkt 1) Kundebase 1 ble installert ved å importere en kopi av Master slik den var på dette tidspunktet
Tidspunkt 2) Kundebase 2 installeres også ved å importere en kopi av Master. 

MBS-modellen sikrer at databasestrukturene i kundebasene er identiske med Master - enten fordi de er kopiert, eller de har vært gjenstand for nøyaktig de samme databaseoppgraderingene som Master, eller en kombinasjon av kopiering og oppgradering.

2.2 Moduler og versjonskontroll

Databaseobjektene i en klient/server-applikasjon eies som regel av egne databasebrukere - såkalte skjemaer. Noen applikasjoner kan ha alle tabeller og andre objekter samlet under ett og samme skjema, mens andre kan ha en oppdelt applikasjon som gjør det naturlig å spre databaseobjektene på to eller flere skjemaer. 

Versjonskontrollen i DUP er ikke knyttet til databasen som helhet, men til Moduler - et sett av databaseobjekter som er gjenstand for versjonskontroll. Det finnes to modeller for versjonskontroll i DUP: Skjemamodulering og subskjemamodulering.

Illustrasjonene nedenfor viser et sett med tabeller og view i en tenkt applikasjon som består av en salgsmodul og en ansattmodul. Modulene selges separat, og det er nødvendig å dele også databaseobjektene i moduler. De to illustrasjonene viser de samme objektene med h.h.v. skjemamodulert og subskjemamodulert versjonskontroll. Viewene i kursiv opprettes og vedlikeholdes av DUP.

2.2.1 Skjemamodulering

Schema SALE

Table CUSTOMER
Table ORDERS
View CUSTOMER_ORDERS
View SCHEMA_VERSION
Schema EMPLOYMENT

Table EMPLOYEE
Table DEPARTMENT
View DEPARTMENT _EMPLOYEES
View SCHEMA_VERSION

Med skjemamodulering regnes hvert skjema i databasen som en modul. Versjonskontrollen ligger da på skjema-nivå: DUP-filene forutsetter pålogging av skjema, og endringene kan dermed gjøres i alle skjemaets objekter. Versjonsuttrykk går også mot skjemaet, og man oppgir ”SCHEMA” som modulnavn. I denne modellen bruker man gjerne begrepet skjemaversjon i stedet for modulversjon. DUP lagrer versjonsnummeret i et view som heter <skjema>.SCHEMA_VERSION.

2.2.2 Subskjemamodulering

Schema COMMON

Module SALE
Table SALE_CUSTOMER
Table SALE_ORDERS
View SALE_CUSTOMER_ORDERS
View SALE_VERSION

Module EMP
Table EMP_EMPLOYEE
Table EMP_DEPARTMENT
View EMP_DEPARTMENT _EMPLOYEES
View EMP_VERSION

Med subskjemamodulering har man flere moduler innen ett og samme skjema. Tabeller og øvrige databaseobjekter tilordnes modulene. Også i denne modellen går Versjonsuttrykk mot skjemaet, men man oppgir i tillegg et modulnavn. Siden man logger på som skjema, tillater databasen endringer i alle objekter. Systemutvikler må dermed selv sørge for at DUP-filer for en gitt modul kun opererer på denne modulens databaseobjekter. Systemutvikler må også selv holde styr på hvilke moduler som finnes, og hvilke objekter som er tilordnet hver modul. Ved subskjemamodulering anbefales det derfor å prefikse objektnavn med modulnavn slik det er gjort i eksempelet. 

Ved subskjemamodulering lagrer DUP versjonsnummeret i et view som heter <skjema>.<modulnavn>_VERSION. 

3 Lage DUP-filer med DUP Designer

DUP Designer er systemutviklers verktøy som brukes til å lage og redigere DUP-filer. DUP Designer brukes også i tilfeller hvor det er ønskelig å åpne en prosessert DUP-fil for å se hvordan kjøringen har forløpt – meldinger, feil, etc.

3.1 Uttrykkene - DUP-filens byggesteiner

En DUP-fil består av en serie uttrykk (statements) av ulike typer. Følgende typer finnes:

Uttrykkstypene har en del egenskaper felles, bl. a. 6 ulike boolske verdier (flagg) som vises som kolonner i skjermbildet:

Flaggene Vital, Always run, Disabled og Executed kan redigeres ved å huke av/på i avkryssingsboksen. Error og Message er kun for å lese.

Les om uttrykkstypenes øvrige egenskaper i kapitlet Uttrykkstyper.

3.2 Oppbygging av en DUP-fil

En DUP-fil starte med et påloggingsuttrykk – Logon statement – for å etablere forbindelse med databasen. Det er ellers ingen regler for hvilke uttrykk som må være med i en DUP-fil. Man står også fritt når det gjelder antall og rekkefølge på uttrykkene.

Likevel vil de fleste DUP-filer ha følgende oppbygging med hode, kropp og hale:

Del

Uttrykk (statement)

Oppgave

Hode

Logon statement

Logger på databasen

Version statement – Check

Sjekker databaseskjemaets eksisterende versjon, og sørger for at DUP-filen stopper hvis versjonen ikke er riktig.

Kropp

Ett eller flere uttrykk av typene

  • SQL statement
  • Parameter
  • Data upload
  • Load Java Files

Utfører endringer i databasen.

Hale

Compile objects

Rekompilering av databaseobjekter som er avhengige av de objektene som ble endret i filens kropp.

Version statement – Update

Sørger for at databaseskjemaets versjonsnummer oppdateres.

3.3 Uttrykksegenskapene Vital, Always run, Disabled, Executed, Error og Message

Uttrykksegenskapene Vital, Always run, Disabled, Executed, Error og Message er felles for alle utrykkstyper. De styrer hvordan uttrykkene skal prosesseres. 

3.4 Feilhåndtering med Vital og Always run

Kryss på Vital er standard på alle uttrykkstyper. Always run er standard på innloggings- og versjonsuttrykk:

Denne konfigurasjonen sikrer at prosesseringen kan kjøres på nytt om en feil skulle oppstå.

Etter at systemutvikler har rettet feilen forsøker kunden å kjøre den på nytt:

Verdiene Vital og Always run kan endres på alle typer uttrykk, men det er neppe aktuelt å overstyre til non-Vital på innlogging eller versjonssjekk. Det kan være nyttig å slå av Vital på enkelte SQL-uttrykk, f. eks. Insert (Non-Vital) etterfulgt av Update (Vital).

3.5 Skjermbildet

Skjermbildets øverste del består av standard windows-komponenter som meny og knapperad. I tillegg befinner uttrykkstabellen seg her. Uttrykkstabellen brukes til redigering av Tittel og flaggene Vital, Always run, Disabled. og Executed. Error og Message kan ikke endres.

Til venstre i uttrykkstabellen finnes en kolonne for merking av uttrykk. Merkede uttrykk har inverse farger (hvitt på svart). Ingen, ett eller flere uttrykk kan være merket. Merkekolonnen har en liten trekant som angir hvilket uttrykk som er gjeldende. Det er alltid ett og bare ett uttrykk som er gjeldende. I merkekolonnen kan man bruke dra-og-slipp med musen til å flytte uttrykk for å endre rekkefølgen.

Skjermbildets nederste del viser detaljer om merket uttrykk. Skillearket Definition er ulikt fra uttrykkstype til uttrykkstype. Se kapitlet Uttrykkstyper.

Mellom de to skjermdelene finnes en delelinje som kan flyttes opp eller ned med musen for å endre skjermdelenes størrelse etter behov.

 

3.6 Åpne DUP-fil

Bruk Knappen Open eller hurtigtast Ctrl-O for å åpne en eksisterende DUP-fil. 

NB! Man må ha lese- OG skriverettigheter til filen, ellers kan man ikke åpne den. Dette innebærer at DUP-filer ikke kan kjøres fra CD.

3.7 Ny DUP-fil

Opprett ny DUP-fil ved å klikke på Ny-knappen , og to dialogbokser kommer opp etter tur. Først Save Database Update (DUP) File som er standard windows lagredialog. 

Deretter kommer dialogboksen DUP properties opp. 

Skriv inn tittel, beskrivelse og kontaktinformasjon.

Velg også hvilken databasedriver DUP-filen skal koples mot.

3.8 Sette inn et uttrykk

Det første uttrykket - Login statement - blir satt inn ved oppretting av ny fil. Sett inn flere uttrykk ved å velge en av uttrykkstypene i Insert-menyen eller velg Insert, Insert statement.

I Choose statement type kan du velge uttrykkstype med musen eller med pil opp/ned, og i Statement title kan du skrive inn tittel på uttrykket hvis du ønsker. (Tittelen kan enkelt redigeres senere når du er i tabellen). Det siste valget du kan gjøre er Insert position in grid - der bestemmer du om uttrykket skal settes inn før eller etter gjeldende rad.

Les om hvordan du bestemmer uttrykkenes egenskaper i kapitlet Uttrykkstyper.

3.9 Redigere uttrykk

DUP Designer lar deg merke uttrykk og kopiere, lime inn, etc. på tilsvarende måte som mange andre elementer i Windows. 

Les om hvordan du bestemmer uttrykkenes egenskaper i kapitlet Uttrykkstyper.

3.9.1 Merke uttrykk

Merking av uttrykk gjøres ved å klikke på venstre kant av uttrykkstabellen. Du kan merke ett eller flere uttrykk.

3.9.2 Flytte et eller flere uttrykk

Flytting kan gjøres med mus eller med Cut/Paste. Bruker du Cut/Paste kan du kopiere eller flytte uttrykk mellom to DUP-filer.

3.9.3 Redigere uttrykksegenskaper

Les om hvordan du bestemmer uttrykkenes egenskaper i kapitlet Uttrykkstyper.

3.9.4 Slette uttrykk

Du kan slette uttrykk med Edit/Delete. Uttrykket blir først merket for sletting, og dette markeres med en grå farge. Merkingen blir opphevet hvis du velger Edit/Delete en gang til. Når filen lagres blir merkede uttrykk ikke tatt med, og de kan ikke gjenopprettes.

3.9.5 Bruke utklippstavlen

Utklippstavlen kan brukes til å kopiere uttykk fra en DUP-fil til en annen. Kopieringen skjer på standard Windows-måte med Ctrl-C for å kopiere og Ctrl+V for å lime inn i en annen DUP-fil.

Utklippstavlen kan også brukes til å konvertere DUP-uttrykk til tekst, d.v.s. SQL og andre kommandoer som DUP processor sender til databasen ved kjøring. Konverteringen skjer ved å merke uttrykk, kopiere og lime inn i en teksteditor.

3.10 Søke etter tekst

Du kan søke etter ord i en DUP-fil ved hjelp av menyen Edit/Find eller Ctrl-F. Skriv inn en søkestreng og klikk OK, og DUP markerer det første uttrykket hvor søkestrengen finnes i tittel eller definisjon. Søket starter på uttrykket som kommer etter gjeldende uttrykk.

Menyen Edit/Find next vil gjøre samme søk på nytt, og stanser på neste forekomst hvis den finnes.

Find og Find next skiller ikke mellom store og små bokstaver.

3.11 Tilbakestille DUP-fil

Ved prosessering av en DUP-fil settes flagget Executed for hvert uttrykk som blir kjørt. Enkelte uttrykk produserer meldinger eller output, og i noen uttrykk oppstår det feil ved kjøring. Alt dette er data som lagres i filen, og må kunne slettes før filen skal kjøres på en annen databaseinstans. 

3.11.1 Fjerne meldinger/utdata

Meldinger og utdata fjernes fra alle uttrykk på en gang ved å velge Edit, Clear all messages.

3.11.2 Fjerne feilmeldinger

Feilmeldinger fjernes fra alle uttrykk på en gang ved å velge Edit, Clear errors.

3.11.3 Tilbakestille fil for ny kjøring

Executed-flagg, meldinger/utdata og feilmeldinger fjernes fra alle uttrykk på en gang ved å velge Edit, Reset

3.12 Importere eksisterende SQL-skript

Du kan importere en eksisterende fil med SQL slik at hvert uttrykk i skriptfilen blir ett SQL-uttrykk i DUP-filen. Det gjøres ved å velge File, Import SQL-script på menyen, og deretter velge en skriptfil. 

Alle SQL-uttrykk som kan kjøres som skript, kan også konverteres til DUP ved å importere. Det gjelder også lengre, komplekse uttrykk som f.eks. oppretting av prosedyrer eller pakker. 

Uttrykkene i filen må være terminert på vanlig måte i skriptfilen.

ORACLE: SQL-uttrykk skal termineres med ; (semikolon), mens PL/SQL-blokk termineres med Line feed (LF) + / (slash). 

Generelt kan altså en kjørbar skriptfil importeres til en DUP-fil og bli ett eller flere kjørbare uttrykk i den. 

Men NB! Skript-kommandoer som ikke inngår i SQL kan ikke kjøres i en DUP-fil.

ORACLE: Dette gjelder f.eks. SQL*Plus-kommandoene DEFINE og SPOOL. 

Du kan få automatisk satt tittel på uttrykkene i DUP-filen. Det gjøres ved å legge inn en kommentarlinje med prefiks "name = " på linjen over hvert uttrykk i skriptfilen:

-- name = Lag kodetabell
CREATE TABLE koder 
    (kode varchar(6),
     beskrivelse varchar(100)
     );

-- name = Lag primærnøkkel
ALTER TABLE koder 
    ADD CONSTRAINT XPKKODETABELL
    PRIMARY KEY (kode);

Ved import av en slik fil vil DUP-filen få to nye SQL-uttrykk med både tittel og definisjon. Tilene blir h.h.v. Lag kodetabell og Lag primærnøkkel. 

3.13 Validering (Validate)

Før prosessering av en DUP-fil vil det alltid bli kjørt en validering. Ved validering sjekkes hvert uttrykks gyldighet ut fra bestemte regler. Det finnes også regler som gjelder filen som helhet. Hvis en eller flere regler er brutt, kan ikke filen kjøres, og det vises en feilmelding. Denne valideringen kan foretas i DUP Designere uten å kjøre filen  ved å velge File, Validate. 

Reglene for hva som gjør et uttrykk gyldig varierer fra uttrykkstype til uttrykkstype. Her er noen eksempler:

Eksempel på regel som gjelder filen som helhet.

Valideringen sjekker ikke om SQL-setningen er riktig eller om oppgitt databaseskjema eksisterer - den valideringen kan bare DBMSen utføre ved kjøring av uttrykket.

3.14 Pakk ved lagring (Pack on save)

Alle DUP-filer komprimeres, men likevel kan DUP-filer blir store hvis de inneholder svært mange uttrykk eller inneholder datauttrykk med store datamengder. Ved avkrysset File, Pack on save vil filen i tillegg defragmenteres før den lagres til fil. En stor fil som har vært gjennom mye redigering og mange lagringer,  kan gjerne bli redusert til en brøkdel av opprinnelig størrelse. Lagring av store filer tar merkbart lengre tid med pakking enn uten. Vi anbefaler derfor å arbeide med Pack on save avslått. Til slutt, ved siste lagring før utsendelse, slås flagget på slik at det endelige resultatet blir en minst mulig fil. Ved Save As skjer defragmenteringen uansett om Pack on save er på eller ikke.

3.15 DUP-filens egenskaper (Properties)

I menyen under File, Properties finner du DUP-filens egenskaper: Tittel og annen informasjon som gjelder DUP-filen som helhet. 

Tittelen (Title) får kunden se mens filen kjøres. 

Beskrivelsen (Description) er til internt bruk for systemutvikler. Hvis man f.eks. ønsker å skrive en kort oppsummering av hva DUP-filen gjør, er dette stedet å skrive. 

Kontaktinformasjon til kunde (Customer contact information) får kunden se hvis filen stopper p.g.a. en feil. Feilmeldingen er slik: 

Please send this file (<filnavn>) to the following contact: 
<Kontaktinformasjon til kunde>.

3.16 Kjør (Process)

Velger du File, Process eller trykker Ctrl-P i DUP Designer, vil filen bli kjørt på samme måte som kundene kan kjøre den ved hjelp av DUP Processor.

NB! Ikke kjør filen hvis du har gjort endringer som skal forkastes! Filen blir lagret først uten spørsmål hvis det er gjort endringer. 

Etter lagring blir filen validert (se Validering) før den setter i gang med å kjøre ett og ett uttrykk. 

3.17 Hurtigtaster i DUP Designer

3.17.1 Filkommandoer

Tastetrykk Menykommando Handling
Ctrl+NFile, NewOpprette ny DUP-fil
Ctrl+OFile, OpenÅpne en eksisterende DUP-fil [mer]
Ctrl+SFile, SaveLagrer DUP-filen 
Ctrl+PFile, ProcessKjører DUP-filen [mer]
Ctrl+REdit, ResetTilbakestiller alle uttrykk slik at filen blir klar for 
ny kjøring [mer]

Noen av kommandoene i DUP Designer er kontekstsensitive, d.v.s. at virkemåten er avhengig av hva som har fokus og hva som er merket i vinduet.
Derfor vil noen av tastekombinasjonene være å finne både under Tekstredigering og under Uttrykksredigering.

3.17.2 Tekstredigering

Tastetrykk Menykommando Handling
Ctrl+XEdit, CutKlipper ut merket tekst og legger den på utklippstavla.
Ctrl+CEdit, CopyKopierer merket tekst og legger den på utklippstavla.
Ctrl+VEdit, PasteLimer inn tekst fra utklippstavla.
Del-Sletter merket tekst
Ctrl+AEdit, Select allMerker all tekst hvis man har fokus på et redigeringsfelt.
Ctrl+FEdit, FindFinn første forekomst av en tekst i filen [mer]
F3Edit, Find nextFinn neste forekomst av teksten. [mer]
F6Edit, Focus detail panelBytter fokus mellom uttrykkstabellen og detaljpanelet.
Ctrl+REdit, ResetTilbakestiller alle uttrykk slik at filen blir klar for 
ny kjøring [mer]

3.17.3 Uttrykkstabellen og redigering av uttrykk

Tastetrykk Menykommando Handling
InsInsert, Insert statementSett inn uttrykk  [mer]
Ctrl+XEdit, CutKlipper ut merket(e) uttrykk og legger det på utklippstavla.
Ctrl+CEdit, CopyKopierer merket(e) uttrykk og legger det på utklippstavla.
Ctrl+VEdit, PasteLimer inn uttrykk(ene) fra utklippstavla.
Ctrl+DelEdit, Delete itemSletter merkete uttrykk
Ctrl+AEdit, Select allMerker alle uttrykk i uttrykkstabellen
Shift+SpaceEdit, Select current
row.
Bytter mellom å merke gjeldende rad, og å merke 
tittelen i gjeldende rad.
Ctrl+F1Edit, VitalSlår av eller på flagget Vital i gjeldende uttrykk
Ctrl+F2Edit, Always runSlår av eller på flagget Always run i gjeldende uttrykk
Ctrl+F3Edit, DisabledSlår av eller på flagget Disabled i gjeldende uttrykk
F6Edit, Focus statement gridBytter fokus mellom uttrykkstabellen og detaljpanelet.
Ctrl+REdit, ResetTilbakestiller alle uttrykk slik at filen blir klar for 
ny kjøring
Skift+Pil opp
Skift+Pil ned
-Merk flere uttrykk
Skift+Home
Skift+End
-Merk alle uttrykk fra gjeldende til første/siste rad.
   

 

4 Kjøring av DUP-filer med DUP Processor

DUP Processor er kundens verktøy som brukes til å kjøre DUP-filer. I DUP Processor er det ingen valg eller innstillinger som kunden kan endre. Han eller hun bare skriver inn skjemanavn, passord, og/eller påloggingsstreng, som regel bare påloggingsstreng, og prosessoren utfører de oppgraderinger filen inneholder. 

Resultatet av kjøringen er enten vellykket eller mislykket. Vellykket er den kun hvis alle uttrykk ble kjørt uten stopp. Hvis f.eks. bruker skriver feil i påloggingspassordet eller i TNS-strengen, stopper filen og brukeren får melding om feilen. 

4.1 Begreper

4.1.1 Validation

4.1.2 Error handling

4.1.3 Transaction handling

4.1.4 Bind variables

4.2 Dup Windows Processor

DUP Processor viser et statusskjermbilde med følgende felter:

Felt Informasjon hentes fra
Job titleTittel på DUP-filen (DUP file properties)
Process statusAntall kjørte uttrykk hittil, og totalt antall uttrykk
Statement titleTittel på uttrykket som kjøres for øyeblikket

4.3 Dup Console Processor

Kall til Console med parametre legges inn i sats-filer som kjøres uten interaksjon med bruker.

4.3.1 Silent mode

5 Uttrykkstyper

5.1 SQL statement (SQL-uttrykk)

Det er SQL-uttrykk som utfører databaseoppdateringene, og feltet Definition kan inneholde hvilket som helst DDL- eller DML-uttrykk som er gyldig for databasen.

DDL-uttrykk (Data Definition Language) brukes til å opprette objekter. Eksempel: CREATE TABLE kodetabell (kode char(2), kodetekst varchar2(16))

DML-uttrykk (Data Manipulation Language) brukes til å legge inn, oppdatere eller slette data. Eksempel: UPDATE kodetabell SET kodetekst='Ugyldig' WHERE kode='UG'

SQL-uttrykk kan også inneholde spørringer som trekker ut data fra databasen. Eksempel: SELECT * FROM kodetabell. Ved prosessering av filen blir resultatsettet lagret i DUP-filen. Hvis kunden returnerer filen, kan systemutvikler ved hjelp av DUP Designer inspisere resultatsettet på uttrykkets skilleark Message/Output.

Oracle: Uttrykk i Definition skal ikke termineres med ; eller / som er vanlig i skriptfiler.

Feltet Check affected rows =: gjelder DML-uttrykk og spørringer, d.v.s. INSERT, UPDATE, DELETE eller SELECT. Hvis man har krysset av dette feltet og oppgitt et antall, vil filen stoppe hvis antallet oppdaterte/selekterte rader er ulikt oppgitt antall. Uansett om feltet er krysset av, kan man etter kjøring se i Message/Output hvor mange rader som ble berørt under oppdateringen.

Feltet Enable parameter scan: Feltet krysses hvis Definition inneholder parameter-referanser. Se uttrykkstypen Parameter.

Oracle: Ett og samme DUP SQL-uttrykk kan inneholde flere uttrykk i en anonym blokk, d.v.s. med BEGIN først og END; til slutt. Dette gir imidlertid ikke like god feilhåndtering som når det er bare ett uttrykk i hvert DUP SQL-uttrykk. Det gir heller ikke mulighet til å sjekke antall berørte rader.

5.2 Logon statement (Påloggingsuttrykk)

Logon dialog er det første uttrykket i enhver DUP-fil, og er nødvendig for å opprette en tilkopling til databasen som skal oppdateres ved hjelp av uttrykkene som følger senere i filen.

Feltet Username (schema) kan inneholde navn på en databasebruker som har rettigheter til å utføre kommende uttrykk. Hvis feltet er blankt, må kunden som kjører filen sette inn et gyldig brukernavn. 

Feltet Password kan inneholde passordet til brukeren. Hvis feltet er blankt, må kunden selv skrive inn riktig passord.

Feltet Connection address kan inneholde påloggingsstreng for databasen. Feltet er som regel blankt fordi kunden selv skal skrive inn denne strengen.

Hvis systemutvikler har fylt ut alle felter, vil filen kjøre uten påloggingsdialog.

ORACLE: DUP-filer som inneholder Java statements må benytte påloggingsstreng på formen <host>:<port>:<sid>, og ikke TNS-streng slik den er definert i TNSNAMES.ORA. NB! Formen <host>:<port>:<sid> støttes IKKE av ORACLE-klienter eldre enn ORACLE 8i.

Feltet Hint/help text kan inneholde informasjon eller hjelp til brukeren som utfører prosessering av filen. F. eks. kan man her instruere bruker i hva som skal fylles ut i feltene.

DUP processor husker sist brukte Username og Connection address slik at brukeren slipper å taste inn denne informasjonen ved kjøring av flere DUP-filer.

Avkryssingsboksen "Disallow other users logged on while processing update" krysses hvis filens påfølgende uttrykk kun skal kjøres hvis alle brukere er logget ut. Hvis det er kryss på denne, vil DUP-filen prosesseres slik:

NB! Før kjøring av et påloggingsuttrykk med kryss på Disallow ..., kjøres en systemkommando som hindrer vanlige brukere å logge seg inn.

ORACLE: ALTER SYSTEM ENABLE RESTRICTED SESSION. For å benytte denne funksjonaliteten må DUP-bruker (skjema) derfor ha rettighetene RESTRICTED SESSION og ALTER SYSTEM. DUP-bruker må dessuten ha leserettigheter til hvilke sesjoner som er aktive: Viewet V$SESSION. 

5.3 Version statement (Versjonsuttrykk)

Som regel er det andre og det siste uttrykket i en DUP-fil et Version statement. (Se Oppbygging av DUP-filer). Denne uttrykkstypen brukes enten til å sjekke eksisterende versjonsnummer, eller til å oppdatere modulen med et nytt nummer.

Feltet Schema name skal fylles ut med navnet på den objekteier (schema) som eier settet med objekter som skal versjonskontrolleres.

Feltet Module name skal inneholde ordet SCHEMA hvis alle schemaets objekter skal versjonskontrolleres under ett. Hvis man har foretatt en logisk modulinndeling av schemaets objekter, skal det her oppgis modulnavn på den modul som DUP-filen skal oppdatere. Les også Moduler og versjonskontroll .

Feltet Version action bestemmer om det er en versjonssjekk eller en versjonsoppdatering. 

I versjonssjekkuttrykk vises feltene Min version number og Max version number. I disse feltene fyller man inn minimum og maksimum versjonsnummer som modulen i pålogget base må ha for at filen skal tillates kjørt mot databasen. Som regel er min og maks versjon den samme, nemlig forrige versjon.

I versjonsoppdateringsuttrykk vises feltet Version number. I dette feltet fyller man ut det nye versjonsnummeret som modulen skal oppdateres til. De fire sifrene i versjonsnumrene er:

  1. Major version - Større versjonsendring
  2. Minor version - Mindre versjonsendring
  3. Major revision - Omfattende revisjon av en versjon
  4. Minor revision - Mindre revisjon - feilretting 

5.4 Data upload statement (Datauttrykk)

Data Upload-uttrykk brukes til å sende ut data til kundene. Systemutvikler henter data fra f. eks. en utviklingsdatabase, og data lagres i DUP-filen. Man må bestemme noen egenskaper ved opplastingen, bl. a. definere i hvilken tabell hos kunden data skal lagres. Når kunden kjører filen mot sin base, vil data lastes inn.

Hent data ved å trykke knappen Retrieve data. Du må oppgi påloggingsstreng, brukernavn og passord til basen der du skal hente data.

5.4.1 Dialogboksen Retrieve data

Hvis påloggingen var vellykket, får du opp dialogboksen Retrieve data. I denne kan du velge hvilken tabell og hvilke kolonner du skal hente data fra. Bruk kombinasjonsboksen Table name, og en eller flere kolonner fra lista Columnlist. Med Ctrl-museklikk kan du velge flere kolonner selv om de  ikke ligger etter hverandre. Valgene du gjør genererer en SELECT-setning i feltet SQL. Hvis data som skal hentes krever en mer kompleks spørring med koplinger og/eller betingelser, kan du skrive spørringen direkte i SQL-feltet. 

Når spørringen er klar, trykker du på Start data retrieve. Hvis det er større mengder data som lastes inn, vil du se antallet nederst i DUP-vinduet. Når innlastingen er ferdig, vil dialogboksen Retrieve data lukkes.

5.4.2 Rammen Data contents

Du kan se det totale antallet rader i feltet Rows loaded. Feltet Source viser hvor data ble hentet fra, og du kan se på data med knappen Browse. Hvis det er mange rader, får du se de 5000 første. Du kan slette data fra uttrykket ved å bruke knappen Clear.

Skriv inn tabellnavn i Destination table. Dette er navnet på måltabellen - tabellen som data skal lastes til hos kunden.

5.4.3 Rammen Upload settings

Velg en av følgende metoder for opplastingen av data:

NB! Hvis metoden Overwrite brukes, MÅ man angi i tabellen Destination columns hvilke kolonner som inngår i måltabellens primærnøkkel.

Feltet SQL Preview viser SQL-setningen(e) som vil bli tatt i bruk ved opplastingen, avhengig av Update method, Destination table og Destination columns.

Feltet Commit after n rows brukes til å bestemme hvor mange rader som skal lastes før transaksjonen commites. Standardverdi er 0, og det innebærer commit etter hver rad. 

Feltet Ignore row upload errors kan brukes hvis man ikke vil at DUP-filen skal gi feilmelding og stoppe på grunn av feil ved innsetting av data. Syntaksfeil blir uansett ikke ignorert. 

5.4.4 Anmerkning som gjelder Oracle

Vi erfart at opplasting av data med CLOB/BLOB-kolonner kan medføre heng i DUP programmet hvis Oracle-klienten er 8i/9i og databasen er 8.0.

Løsning på dette er å kjøre Oracle 8.0 klient.

5.5 Compile objects statement (Kompiler objekter)

Uttrykk av typen Compile objects brukes til å rekompilere objekter i databasen. Dette er nyttig etter at man har endret et objekt (f. eks. et VIEW) som benyttes av et annet objekt (f. eks. en PROCEDURE). Sistnevnte objekt blir ugyldig etter oppdateringen av førstnevnte, og sistnevnte må rekompileres.

Feltet Schema fylles inn navn på eier av de objekter som skal rekompileres.

Avkrysningsboksene brukes til å bestemme hvilke typer objekter som skal rekompileres.

5.6 Load java files statement (Lasting av Java-filer)

Oracle f.o.m. versjon 8i har muligheten til å bruke java-klasser som lastes inn i databasen. Klassene kan instansieres på databaseserveren, og kalles fra spørringer, view og PL/SQL.

Oracle leverer verktøyet loadjava som brukes til å laste filer inn og opprette dem som objekter. Man kan laste inn java kildekode (.java-filer), java bytecode (.class-filer), java ressurser eller pakker (.jar eller .zip-filer) som inneholder kombinasjoner av disse filtypene. 

DUP-uttrykkstypen Load Java Files gjør kall til loadjava ved prosessering, og eliminerer dermed direkte bruk av det. Hensikten er forenkling ved å samle all oppgraderingen i ett og samme verktøy, og å inkludere java-kode i den samme versjonskontrollen som øvrige databaseobjekter.

Forutsetninger for bruk:

Knappen Add files brukes til å bygge opp en liste over filer som skal lastes inn. Merkete filer kan fjernes fra lista med knappen Remove files. Ved prosessering vil alle filer på lista bli lastet inn i ett og samme kall til loadjava.

Privileges: Velg om objektet ved bruk skal ha rettigheter som den som laget objektet (Definer) eller som den som har tatt det i bruk (Invoker).

Force load: Last inn alle filene uansett om noen av de måtte være lastet inn i samme versjon tidligere.

Create public synonym: Oppretter synonym slik at alle får tilgang til objektet

Order: Last inn filene i rekkefølgen som er oppgitt i lista. Dermed overstyres standard innstilling som er rekkefølgen gitt av de ulike objektenes avhengighet av hverandre.

Schema (If different from current): Skriv inn skjema hvis javaobjektene skal lagres i et annet skjema enn det som er DUP-filens påloggete

Grant execute to (comma separated list of users): Skriv inn navn på brukere som skal ha kjørerettigheter til objektene.

Resolver specification: Tilsvarer classpath i Java: En spesifikasjon av hvor Oracle skal lete etter javaklasser som de innlastede filene benytter. Skriv inn foretrukne skjemaer først.

Les flere detaljer om parametre til loadjava i Oracle 8i /9i Java Tools Reference.

5.7 Parameter statement (Parameter)

Parameter-uttrykk gjør det mulig for DUP-filen å "huske" verdier over flere uttrykk. Dette er nyttig hvis man ønsker å spørre bruker etter en kundespesifikk verdi som skal brukes i videre kjøring, eller hvis man vil hente en verdi fra kundebasen som skal brukes i senere uttrykk.

Det finnes fire type parametre: Output bind, Input Bind, Input/Output bind og Substitution. Forskjellen på substitution- og bind-parametere er at substitution-parameteren blir erstattet med en verdi før uttrykket sendes til databasen.

Alle parametrene er av typen STRING.

I ORACLE kan du likevel bruke datoer eller tall i.o.m. at ORACLE konverterer parametere til relevant type ut fra språk-/landoppsettet på ORACLE-klienten.

5.7.1 Input bind-parameter

Du ønsker å å lage en DUP som skal brukes ved installasjon hos nye kunder. Du vil be installatør om en ID som skal knyttes til den nye kunden, og som legges inn i kodetabellen OPTIONS.

Du trenger 2 uttrykk for å få til dette:

  1. Et parameteruttrykk som stopper DUP-prosesseringen, og lar installatør taste inn en ID
  2. Et SQL-uttrykk som setter inn data i options-tabellen.

Parameteruttrykket settes til typen Input bind parameter, og feltet User prompt settes til "Kunde-ID". I feltet Parameter name skriver du et navn på parameteren, f. eks. kunde_id. Feltet Default value brukes når man vil at en parameter skal ha en standardverdi, men det er ikke aktuelt i dette tilfellet.

Til slutt settes eventuelt en inputvalidering. I dette tilfellet skal kundens ID være en varchar2(6), så sett gjerne minimum lengde til 2, og maksimum lengde til 6. 

Etter parameteruttrykket kan følgende SQL-uttrykk legges inn:

  INSERT INTO options (option_id,  option_value)
  VALUES              ('KUNDE_ID', :kunde_id);

NB! SQL-uttrykket må ha avkrysset feltet Enable parameter scanning.

Input kan valideres i detalj ved å bruke inputmaske (Input mask). Her kan man f.eks. skrive >LLL000, og det blir bare tillatt å skrive en kode som består av 3 kapitéler og deretter 3 tall. Appendix A - Parameter Validation Mask inneholder utførlige beskrivelser av alle tegn som kan brukes i en maske.

5.7.2 Output bind parameter og Input/ Output bind parameter

Output-parametre brukes når man har behov for å få ut en verdi fra databaseserveres som ikke kan hentes med et enkelt select f.eks. fordi den må kalkuleres eller aggregeres. Dette kan være nyttig ved debugging.

5.7.3 Input substitution parameter

Denne typen parametre erstattes med parameterverdi i DUP Processor før uttrykkes sendes til serveren. Dette kan være nyttig for oppretting av objekter som er avhengig av fysisk plassering hos kunde. Eksempel: 

CREATE TABLESPACE DUP_DEMO_DATA datafile '&dup_tablespace_file&/dup_data.dat' size 10M

 Her vil et parameteruttrykk få DUP Processor til å stoppe og spørre installatør om hvilken path/fil tablespace skal lagres på.

NB! SQL-uttrykkene må ha avkrysset feltet Enable parameter scanning.

6 Appendix A - Parameter Validation Mask

(Jfr. parameter-uttrykk)

Use a mask to restrict the characters a user can enter into the control to valid characters and formats. If the user attempts to enter an invalid character, the edit control does not accept the character. Validation is performed on a character-by-character basis.

A mask consists of three fields with semicolons separating the fields. The first part of the mask is the mask itself. The second part is the character that determines whether the literal characters of a mask are saved as part of the data. The third part of the mask is the character used to represent unentered characters in the mask.

These are the special characters used in the first field of the mask:

CharacterMeaning in mask
!If a ! character appears in the mask, optional characters are represented in the EditText as leading blanks. If a ! character is not present, optional characters are represented in the EditText as trailing blanks.
>If a > character appears in the mask, all characters that follow are in uppercase until the end of the mask or until a < character is encountered.
<If a < character appears in the mask, all characters that follow are in lowercase until the end of the mask or until a > character is encountered.
<>If these two characters appear together in a mask, no case checking is done and the data is formatted with the case the user uses to enter the data.
\The character that follows a \ character is a literal character. Use this character to use any of the mask special characters as a literal in the data.
LThe L character requires an alphabetic character only in this position. For the US, this is A-Z, a-z.
lThe l character permits only an alphabetic character in this position, but doesn't require it.
AThe A character requires an alphanumeric character only in this position. For the US, this is A-Z, a-z, 0-9.
aThe a character permits an alphanumeric character in this position, but doesn't require it.
CThe C character requires an arbitrary character in this position.
cThe c character permits an arbitrary character in this position, but doesn't require it.
0The 0 character requires a numeric character only in this position.
9The 9 character permits a numeric character in this position, but doesn't require it.
#The # character permits a numeric character or a plus or minus sign in this position, but doesn't require it.
:The : character is used to separate hours, minutes, and seconds in times. If the character that separates hours, minutes, and seconds is different in the regional settings of the Control Panel utility on your computer system, that character is used instead.
/The / character is used to separate months, days, and years in dates. If the character that separates months, days, and years is different in the regional settings of the Control Panel utility on your computer system, that character is used instead.
;The ; character is used to separate the three fields of the mask.
_The _ character automatically inserts spaces into the text. When the user enters characters in the field, the cursor skips the _ character.

Any character that does not appear in the preceding table can appear in the first part of the mask as a literal character. Literal characters must be matched exactly in the edit control. They are inserted automatically, and the cursor skips over them during editing. The special mask characters can also appear as literal characters if preceded by a backslash character (\).
The second field of the mask is a single character that indicates whether literal characters from the mask should be included as part of the text for the edit control. For example, the mask for a telephone number with area code could be the following string:
(000)_000-0000;0;*

The 0 in the second field indicates that the Text property for the edit control would consist of the 10 digits that were entered, rather than the 14 characters that make up the telephone number as it appears in the edit control.

A 0 in the second field indicates that literals should not be included, any other character indicates that they should be included. The character to indicate whether literals should be included can be changed in the EditMask property editor, or programmatically by changing the MaskNoSave typed constant.

The third field of the mask is the character that appears in the edit control for blanks (characters that have not been entered). By default, this is the same as the character that stands for literal spaces. The two characters appear the same in an edit window. However, when a user edits the text in a masked edit control, the cursor selects each blank character in turn, and skips over the space character.

7 Appendix B - Innføring av DUP

Innføring av DUP i et utviklingsmiljø innebærer implementering av MBS-modellen. Hvis DUP skal tas i bruk i eksisterende utviklingsprosjekter, må innføringen starte med noen analyser og eventuelle tiltak.

Forutsetningen for å innføre DUP er at det etableres en Masterdatabase som inneholder alle databaseobjekter og systemdefinerte data. Masterbasen skal være kopieringsoriginal ved installasjon av nye baser. Objekter og systemdefinerte data i kundenes baser skal være identiske med master. Før Masterdatabase kan etableres må man derfor finne og korrigere så mange som mulig av ulikhetene mellom kundebasene.

Noen ulikheter er tilsiktede, og andre kommer av feil eller uregelmessigheter som har oppstått. Et eksempel på en tilsiktet ulikhet som vi har erfart å måtte korrigere, var i et system med omfattende logging av endringer. Alle sentrale tabeller var utstyrt med triggere som lagret gamle og nye verdier sammen med tidspunkt og brukernavn. Omfanget på loggingen kunne hver kunde bestemme; de kunne sette opp nøyaktig hvilke felter de ønsket å logge. Ved lagring av et slikt oppsett genererte applikasjonen en ny oppdateringstrigger som ble lagt på tabellen. Dette innebar at ulike kunder hadde ulike triggere - et brudd på MBS-modellen.

Tilsiktede ulikheter må fjernes ved endring av modellen. I dette tilfellet det ble opprettet en tabell med informasjon om hvilke felter som skal logges. Triggeren (den samme hos alle kunder) slår nå opp i denne tabellen før den utfører loggingen.

Tilfeldige ulikheter er gjerne vanskelig å skaffe seg oversikt over gjennom analyse. Et eksempel kan være en kolonne som mangler hos enkelte kunder fordi et skript ikke er blitt distribuert til alle. Det kan være hensiktsmessig å rette slike ulikheter etter hvert som man får feilmeldinger. Opprettingen skjer ved at kunden returnerer filen som stoppet opp, og man gjør oppgraderingsdupen om til en spesialdup - en fix - for vedkommende kunde. Spesialdupen endrer kundens database slik at den blir lik Master. Filen sendes til kunden som kjører den på nytt.

Grovt skissert består innføringen av DUP av følgende operasjoner:

  1. Finn DDL-objekter som med hensikt er laget ulikt fra base til base
  2. Hvis slike objekter finnes lages ny løsning med like objekter og ulike kundedata
  3. Bygg masterdatabasen med ny løsning
  4. Baselining: Lag den første oppgraderings-DUPen. Den må endre kundenes baser til de alternative løsningene fra punkt 2. DUPen inneholder dessuten det første version update statement. Man gir modulen et versjonsnummer.
  5. Sammenlikn eventuelt kundebasene med masterbase, og ved ulikheter lages og kjøres individuelle DUPer som retter kundenes baser
  6. For hver baselining som fører til feil, rettes kundebasene til å bli lik Master.