Problemer med DBCheckBox !

Du skal bare overstyre \"GetText\" og \"SetText\" for dit datafelt. Dobbelt klik på din TTable og vælg \"Add all Fields (hvis du ikke allerede har gjort det). Vælg nu det felt det drejer sig om og skriv en GetText og SetText event for dette felt. Nedenstående er hvordan jeg gør deet du efterlyser (dog op mod en InterBase tabel hvor jeg fysisk i databasen bruger en SmallInt som True/False).

<SNIP>
procedure TFormDbAdmUsers.dsetUsersPWD_EXPIREDGetText(Sender: TField;
  var Text: String; DisplayText: Boolean);
begin
  if Sender.AsInteger = 1 then Text := \'TRUE\' else Text := \'FALSE\';
end;

procedure TFormDbAdmUsers.dsetUsersPWD_EXPIREDSetText(Sender: TField;
  const Text: String);
begin
  if AnsiUpperCase(Text) = \'TRUE\' then Sender.AsInteger := 1
                                  else Sender.AsInteger := 0;
end;
</SNIP>

TTable op mod Oracle - du skulle skamme dig  :-)  I et C/S miljø burde det ikke være muligt at bruge TTable da de medføre et større overhead i forhold til TQuery.

Ok. Jeg kan da godt skamme mig lidt.
Men du må gerne lige uddybe hvorfor det lige er, at jeg skal skamme mig.
Hvad er det lige du mener med, at en TTable medfører et større overhead end en TQuery?

Mere kommunikation. Altså mere trafik eller hvad)?

Ellers tak for dit svar, men nu bliver jeg altså nysgerrig med det overhead. :-)

Hvis man bruge en filbaseret database som Paradox eller lignende så kan det være udmærket at bruge en TTable, men når du bruger en \"rigtig database\" (så som Oracle, InterBase, MS-SQL og lignende) så burde TTable ikke være tilladt. Du kan sammenligne det med at bruge en slå søm i med en skruetrækker - det kan godt lade sig gøre men det er ikke ideelt.

Jeg skal ikke kunne sige om TTable i forhold til TQuery \"stresser\" database serveren mere (når vi taler CPU), men når vi taler netværkstraffik så har jeg hørt målinger der viser at en TTable generere 30% mere netværkstrafik end en TQuery. Hvis du kun har nogle få maskiner så kan 30% ekstra traffik være \"en detalje\", men med flere brugere kan det være et seriøst problem.

Jeg tror faktisk på dig. (Er du så ikke glad?).

Jeg har på et tidspunkt lavet et lille testprogram netop med TTable op imod et TQuery.
Det var en forholdsvis simpel SELECT statments, der hentede omkring et par tusinde records fra Oracle DB.
TQuery udførte jobbet tæt på FEM gange så hurtigt.
Den kan men i hvert fald seriøst måle, så jeg er begyndt at overveje at udfase mine TTables.
Du gav mig nu bare endnu en grund til det.
DBCheckBox kan vel også køre på en TQuery kombineret med en TDataSource.

Ja NU har du redet min weekend :-)

Jeg skal ærligt indrømme at jeg ikke selv har lavet nogle TTable/TQuery test i et C/S miljø, men alle dem der ved hvad det handler om har tudet mig ørene fulde af at det forholdt sig sådan - og da disse var nogle af branchens tunge drenge tog jeg deres ord for det. At du har set en 5 gange så høj performance med TQuery over TTable er blot \"mere vand på den mølle\". Ligeledes skal passe på ikke bare vender dig til at lave en \"SELECT *\". Nøjes med at vælge kun lige nøjagtigt de felter du har brug for - vil også nedbringe det \"stress\" du placere på DB-serveren og på netværket.

\"Tricket\" med DBCheckBoxen løses på nøjagtig samme måde i en TQuery.

Ja. Nu ved jeg ikke om min test har været særlig videnskabenlig gennemgribende. Jeg tvivler voldsomt på, at de fem gange hurtigere holder i længden. Pointen er bare, at TQuery i hvert fald er hurtigere end TTable. Men er den bare 25% hurtigere i snit er det jo også meget.

Nu siger du også, at man kun skal SELECT\'te på det man skal bruger. Det er også rigtigt. Derudover kan du f.eks også bruge INNER JOIN i stedet for den alm WHERE.
Den giver også noget (Der er ikke et øje tørt).

<LOL> og en IN kan også i nogle tilfælde være hurtigere end OR - men så\'n er der så meget.