Tekstfelter i MSsql forsvinner

[mysjkin]

Jeg skal porte en applikasjon fra en access backend til mssql. Denne applikasjonen er basert på TDatabase -> Ttable og snakker med mssql via ODBC. Jeg får opp alle feltene i databasen gjennom Microsoft Query, men delphi finner tilsynelatende ikke tekstfeltene

 

Hvis jeg prøver å åpne en tabell får jeg melding av typen Type mismatch for field Xxxx, expecting 'String' (hvilket er korrekt, den er definert som string fra før) actual: unknown.

 

Hvis jeg fjerner feltene og prøver å legge dem inn igjen, får jeg ikke opp tekstfelter, det samme om jeg oppretter tabellen på nytt.

 

Noen som kjenner til dette? Eventuelt hvilke databasekomponenter er best å bruke når jeg i allefall må oppgradere applikasjonen?

 

M.

[DidzisK]

Jeg bruker TADOQuery som kobles til MSSQL server via en sentral TADOConnection komponent (bruker OLE DB provider for MSSQL server i connectionstringen).

 

Ulempen med TTable er at du får mange lag med DB komponenter, og ingen av de er veldig godt egnet til oppgaven:

 

- ODBC (veldig generell MS datakoblingslag, kjent for å være treg, gammel teknologi), denne bruker en driver for å koble seg opp mot "native" MSSQL klient

 

- BDE (Borlands DB motor laget for å kommunisere med Paradox og dBase, utvidet for å støtte de mest generelle funksjonene i andre teknologier, bl. a. ODBC)

 

- TTable er egentlig wrapper rundt BDE representasjon av Paradox tabell

[mysjkin]

Jo takk, jeg er klar over at TTable / BDE har sine, eeeh, begrensninger... Applikasjonen ble påbegynt på et tidspunkt hvor det var eneste alternativ (Delphi 2).

 

Det kan se ut som om det må i alle fall røskes grundig opp i databaselaget, så jeg tar en titt på ADO. Noe spesielt jeg skal passe på i den overgangen?

 

M.

[DidzisK]

Noen få punkter som jeg kommer på med en gang

- Bruk MDAC 2.8 (XP inneholder disse allerede), det er bare anbefaling

 

- (det vet du allerede) Det er aldri en god idé å bruke tabelltype komponenter mot en SQL base. Jeg anbefaler å bruke TADOQuery fremfor TADOTable

 

- Selv om det kan virke tungvindt, kan det lønne seg å legge all SQL kode i Stored Procedures. Fordeler - prosedyrene kompileres, så de er raskere (dog ikke første gang). Delphi kode blir ryddigere. Du får tilbakemelding med en gang hvis noe er feil i SQLen. Så hos oss er det ganske ofte TADOStoredProc i stedet for TADOQuery

 

- Bruk parametere (TParameter), ikke prøv å endre SQL teksten dynamisk, selv om det er lov. Det er både sikkerhetsrisiko og ganske tungvindt når du må konvertere alt til string

 

- (gjelder bare MSSQL server 2000 og oppover) Bruk table type variables ("@table@"), ikke temp tabeller ("#table") for temporære tabeller - da blir alt kjørt i minnet og du slipper å slette tabellen når den ikke lenger er i bruk

 

- selvfølgelig ønsker du bare å ha en kobling mot basen. Opprett en global datamodul sett opp en kobling der og bruk den i alle andre moduler

 

- noen ganger kan det lønne seg å tenke på kursortype. Jeg har opplevd at jeg reduserte tid på en rutine med 3 minutter (fra totalt 4 minutter) ved å sette opp query slik at kursoren er på serverside og bare går en vei - det var mange linjer som skulle hentes fra DB for så å beregne ca hundre ganger færre linjer som skulle lagres i basen. Da slapp jeg det at alt av data ble hentet ned til klienten i en (dobbel ?) buffer som blir brukt for å kunne navigere datasettet mange ganger fremn og tilbake. Men i mer enn 99% av tilfellene bruker jeg det som kommer som default.

[mysjkin]

takk for info! meget bra, jeg fikk i hvert fall opp alle feltene når jeg koblet opp med ADO-komponenter. Kommer nok tilbake og spør mer etterhvert!

 

M.