Råd ang. design af tilgang til database

ADO (dbGo) er min foretrukne. Efterhånden er jeg ved at have så meget styr på det at jeg ville kombinere det med TClientDataSet, men du kunne sagtens bruge TADOQuery direkte. Evt. med LiveUpdate hvorved den opfører sig som en TADOTable, men uden en masse baggrundsdata (såsom indekser og constraints). Det er mest effektivt at bruge TADOQuery.

ADO (dbGo) er ligeledes min foretrukne.
Men et lidt dumt spørgsmål: Hvorfor dog ikke anvende MSSQL (Express edition er GRATIS!!)
En tabel med 150000 records lyder af temmelig meget, og en ACCESS database kan med dette antal records komme ud af trit med indexer. I MSSQL er det heller ikke noget issue at andre opdaterer basen. Hele MSSQL maskinen tager hånd om dette. Ved brug af ClientDataset (hvilket jeg også foretrækker) er det blot "Refresh" metoden og "ApplyUpdate(0)" metoden der klarer sagerne (men husk at opsætte DatasetProvideren korrekt)

m.v.h.
Anders

Anders: Jeg bruger også CDS, men synes konceptet har noget "Fuzzy logic" over sig. Tidligere har vi oplevet at der blev lavet temporære Paradox-tabeller; noget der skal gøres med forsigtighed på et Citrix-system! Det er vist fjernet nu.

Dokumentationen er noget skod og det er mærkeligt man ikke retter fejlen med kopiering af felter fra clientdata-sættet til provideren. Når man kører UpdateMode=upWhereKeyOnly skal man huske OnUpdateData-eventen hvor den primære nøgle må sættes manuelt: DataSet.FieldByName('ID').ProviderFlags := [pfInKey];

Jeg er her endnu..
Jeg har overvejet det med MSSQL det bringer mange fordele med sig, Da der en del af den anden funktionalitet MSSQL har der evt. kan bruges. Ulempen er at den skal ligge på maskinen ( der er office på maskinerne nu).
Jeg kan se at der er sket noget med Delphi siden jeg sidste brugte den, Men det er ikke alt der er til det bedre. Selve brugermiljøet virker mere "rodet", men det er nu nok en vanesag.


Læg et svar begge da jeg syntes at i beggge angiver en fornuftig løsning.

Hilsen Claus

Jeg må indrømme at jeg har meget svært ved at få øje på ulemperne i forbindelse med CDS. Og m.h.t. MSSQL er den helt store fordel jo at den kan tilgås fra mange arbejdsstationer samtidig uden man behøver at spekulere på "låsning" af filer etc.
M.h.t. CDS er der KÆMPE fordele:
- Man kan begrænse connection til serveren til et absolut minimum (ADOConnection1.KeepConnection := False)
- Man kan i Master-Detail relationer gøre brug af "Nested dataset" (d. v. s. felter af typen TDatasetField)
- Man kan gøre bruge af aggregat funktioner
- Man kan lave felter af typen InternalCalc hvorefter kolonner kan sorteres på disse felter også

- Og mange flere

itg: Ulempen for mig har klart været, at noget der normalt virker, ikke gør det når jeg forsøger i CDS. Brugte 4 timer i går, på at lave en master-detail (m. MasterSource og MasterFields) løsning hvor jeg, foruden masterens (af CDS, automatiske) primærnøgle, også havde brug for at kunne angive to flag (aktiv og inaktiv).

Havde altså et detail-script i denne orden:

select id, navn, aktiv from <tabel> where (aktiv=:aktiv or aktiv=:inaktiv). CDS forsøger selv at lave master-nøglen i scriptet, men det bliver kun de to ovennævnte; hvorfor forsøgene fejlede.

Felterne i CDS var sat op som jeg plejede, med ID som pfInKey og de andre felter pfInUpdate. Programmet blev ved med at sige at nogle parametre ikke var sat og intet, jeg gjorde, hjalp. Fik det til at virke ved at fjerne where-linjen og filtrerer nu et andet sted i koden.

Det synes jeg er noget skod!

En anden ting er at det er InMemory-dataset. Lad være med at hente hele fakturalinje-tabellen over i en klump for så bliver der ædt rigtig meget hukommelse (brug PacketRecords).

En anden ting jeg gerne vil med en CDS er at den kalder en StoredProcedure i stedet for at generere SQL-scriptene selv. Heri vil jeg automatisere en del ting såsom fremfindelse af autoinc primærnøgle v. indsættelse, samt håndtering af oprettelses- og modifikationsdato og bruger. Har set det beskrevet et eller andet sted - men der står intet i hjælpen om hvordan man griber det an. Det er en fordel at kunne debugge VCL-koden.

Jeg synes dog godt om CDS, men det er ikke den perfekte løsning, absolut ikke!

hrs
???
Prøv følgende:
MasterTabel : FarOgMor
- iFarOgMorID int IDENTITY(1,1) PRIMARY KEY
- <andre felter>

DetailTabel : Boern
- iBoernID int IDENTITY(1,1) PRIMARY KEY
- iFarOgMorID int
- <andre felter>

I Delphi:
qryFarOgMoer : TADODataset, CommandText = "SELECT * FROM FarOgMor" (evt. WHERE ???)
qryBoern : TADODataset, CommandText = "SELECT * FROM Boern WHERE iFarOgMor = :iFarOgMoer"
prvFarOgMor : TDatasetProvider, Dataset = qryFarOgMor
dsrFarOgMor : TDataSource, Dataset = qryFarOgMor
qryBoern : Datasource = dsrFarOgMor
MasterFields : iFarOgMorID (FarOgMor) <--> iFarOgMorID (Boern)
cdsFarOgMoer : TClientDataset, DatasetProvider = prvFarOgMor
Dobbeltklik på CDSFarOgMor, -->AddAllFields
- Ud over alle felter i FarOgMor, kommer feltet "cdsFarOgMorqryBoern" af typen DatasetField
cdsBoern : TClientDataset, NB! INGEN Provider, men DatasetField = cdsFarOgMorqryBoern

Lukker