Fra Delphi5/BDE til ???

Jeg har laget en komplett Kalkulasjon/MPS/ERP løsning i Delphi5/BDE med Pradox relasjonsdatabase. Dataflyten er utviklet mot kunder i over 10 år. Stort potensiale i markedet.
Parallelt med volumsalg av denne fra høsten, vurderer jeg å sette igang et rent utviklingsprosjekt sammen med noen av de større kundene for

a) Få løsningen over på SQL plattform

b) Lage en helt ny versjon med samme funksonalitet++, men system/programmering styrt av en 'mester i faget' og med optimalt valg av programmeringsverktøy.

Jeg vil sette pris på gode råd / synspunkter på hvordan dette best kan gjøres. Er det noen som har erfaring med å få Paradox-løsning over på SQL?

Dersom du er den 'mesteren i faget' jeg er på jakt etter, kan dette være ditt livs sjanse til å bli med i føresrsetet på noe spennende.

Ta gjerne kontakt på på telefon 48033323 eller mail shagatun@autocalc.no

Steinar Hagatun

Hei!

Jeg for min del har relativt positive erfaringer med å gå over fra Paradox til Firebird, en plattformuavhengig gratis SQL client-server database. Jeg fortsatte utviklingen på delphi/win32 platformen og beholdt mye av kildekoden.

Her er noen av mine synspunkter.

Dersom applikasjonen din ikke er altfor stor, kan det muligens lønne seg å skrive alt på nytt. Er den "stor" kan det virke litt vel omfattende å skulle skrive alt på nytt. Så spørs det om man har sterke ønsker om å benytte et bestemt utviklingsverktøy og hvor mye dette betyr. Men jeg mener absolutt at CodeGear RAD Studio/win32 sammen med en del av dagens tilgjengelige tredjeparts komponenter bør kunne benytts, hvis det viser seg å være vesentlig enklere å beholde kode enn å skrive på nytt.

Jeg har ikke sjekket om BDE fortsatt støttes. Selv brukte jeg Interbase datasett komponenter når jeg gikk over til Firebird, men brukte BDE for å gjennomføre konvertering. Konvertering kan evt. gjøres via et delphi 5 program.

Noen fasit finnes for øvrig neppe. Omfanget av prosjektet vil avhenge av mange spørsmål. Det samme vil valg av utviklingsvektøy. Dersom du fortsetter med delphi/RAD studio vil prosjektets omfang fortsatt påvirkes av ulike faktorer. Deriblant hvilken grad datatilgangen er sentralisert/generalisert (f eks i et eget data aksess lag), og forutsetninger i kriker og kroker i programmet som man av en eller annen grunn ikke har oversikt over før man går i gang. Vanligvis finnes det noen av disse.

Hvilken database du bør velge blir en strategisk vurdering i tillegg til smak og behag. Har du få brukere per installasjon og de ikke er villige til å betale ekstra for database lisenser, vil etter min mening Firebird være aktuelt å vurdere sammen med gratisutgaver av MS SQL Server eller annet. Visse kunder (gjerne de større, som betaler for databaselisensen) kan i noen tilfeller finne på å stille krav til hvilken database som skal benyttes. Det medfører at det kan være lurt å ha tatt høyde for flere typer database allerede i utgangspunktet slik at mulighetene for innsalg hos større kunder ikke hemmes av for lite fleksibilitet i databasevalg.

Jeg for min del er generelt skeptisk til in-process databaser hvor det ikke finnes en egen databaseserver som håndterer datatilgangen. Disse kan likevel ha den fordelen at de er lettere for ukyndige brukere å installere.

Nær sagt enhver client server sql database har en del vesentlige forbedringer i forhold til flatfil baserte paradox. Samtidig har de også noen "ulemper". Visse typer operasjoner som før gikk ganske kjapt i paradox kan ta tid i client-server SQL baser. Og omvendt. Utfordringen blir derfor å gjøre de grepene som utnytter den nye teknologien optimalt, overalt hvor det er nødvendig, og på en riktig måte. For å sørge for at man enkelt gjør det på "riktig måte", er jeg tilhenger av å generalisere/isolere de tekniske aspekter som utgjør 80% av det man bruker tid på i egne rammeverk. Det gjør det enklere å fokusere på annet innhold i programvaren for eksempel det bruker-faglige.

En typisk fare ved å skrive alt på nytt er at man i litt for stor grad lar seg friste til å "forbedre" brukergrensesnittet. I denne prosessen risikerer man å overse funksjonalitet som eksisterende fornøyde brukere allerede har vent seg til å dra nytte av. Endringer her kan framprovosere en del misnøye hos tidligere godt fornøyde brukere. Det er etter min mening derfor viktig å identifisere alle kvalitetene i dagens produkt så godt som mulig og beholde dem enten som de er eller i en forbedret form sett fra kundens ståsted.

Odd Børtveit

Kan bekrefte at Paradox/BDE fungerer helt ok i BDS2006. Bruker det fortsatt daglig. Lettvint når det er masse annet utviklingsarbeide som må gjøres, og tabellene kun fungerer som lager for opplysninger som av brukerne brukes i form av krypterte binærtrær.