Hi@ all

ich möchte in einer Access - Tabelle die Einträge zählen.
Dazu gehe ich wie folgt vor.

markieren

Delphi-Quellcode:

Q := TADOQuery.Create(Self);
  Q.Connection := ADOConnection1;
  Q.SQL.Add('SELECT COUNT(*) FROM Verwaltung');
  Q.ExecSQL;

Wie bekomm ich jetzt die Rückgabe, also das Ergebnis von Count?

Gruß
Karsten

zusammenfalten · markieren

Delphi-Quellcode:

  Q := TADOQuery.Create(nil);
  try
  Q.Connection := ADOConnection1;
  Q.SQL.Text := 'SELECT COUNT(*) AS Anzahl FROM Verwaltung'; // nicht .Add() sondern .Text :=
  Q.Open;

// Alternative 1
Result := Q.Fields[0].AsInteger;

// Alternative 2
Result := Q.FieldByName('Anzahl').AsInteger;
  finally
    Q.Free;
  end;

Warum nimmst Du nicht:

markieren

Delphi-Quellcode:

 Q := TTable.create(self);
 Q.Connection := ADOConnection1;
 Count := Q.RecordCount;
 Q.Free;

Hinweis

Die angegebene Anzahl der Datensätze kann kleiner sein als die Gesamtzahl der Datensätze in der Tabelle. Dies ist der Fall, wenn die abgerufenen Datensätze eine bedingte Teilmenge der Tabelle sind.

Ich kann mir einfach nicht merken, ob die Tabelle offen oder geschlossen sein muss...


mfg Frank

Werde ich mal ausprobieren.
Besten Dank Erst mal

@Mavarik: Dein Vorschlag hat leider eine sehr schlechte Performance.
Stell dir vor, die Tabelle hat sehr viele Felder und 50000 Datensätze.
TTable (müsste eigentlich TADOTable sein) würde nun diese ganzen Datensätze abrufen
obwohl die einzig benötigte Information die Anzahl der Datensätze ist.

Bei wenigen Datensätzen fällt das Problem nicht auf; aber später in der Praxis wird
die Datenbank immer grösser und irgendwann muss man Minutenlang auf ein Ergebniss warten

Das kann niemals so sein...

OK Muss natürlich TADOTable sein!

Aber die ADOTable holt nicht alle Datensätze um die Anzahl zu ermitteln...!

Frank

Zitat von Mavarik:

Aber die ADOTable holt nicht alle Datensätze um die Anzahl zu ermitteln...!

Das hängt bei ADO von der CursorLocation ab. Bei clUseClient werden alle Datensätze zum Client transportiert.
Bei clUseServer werden Datensätze nur auf Anfrage des Clients geliefert.
Die Belastung mit den vielen Daten wird somit nur dem Server untergeschoben.
Der Ms SQL Server hat so unter Umständen schwer zu kämpfen, denn die Abfrage wird eben serverseitig ausgeführt.
Die Jet-Engine (Access) ist ein Sonderfall, da Server und Client der gleiche Rechner ist.
Bei clUseClient findet eine bremsende Doppelpufferung statt.
Nichtsdestotrotz bewirkt ein Aufruf von TADOTable.RecordCount in der Jet-Engine ein "Full Table Scan",
während "SELECT Count(*) FROM ..." um ein mehrfaches Effizienter ausgeführt wird.

Ach ja und die ADOTable muss offen sein!

Bei mir benötigen 200.000 Aufrufe auf 2 verschidene Datenbanken... Einmal 120.000 Datensätze und
einmal 70.800 Datensätze ca. 77 Millisekunden!

Xeon 2,6 GHz

Frank

Zitat von Mavarik:

Ach ja und die ADOTable muss offen sein!
Bei mir benötigen 200.000 Aufrufe auf 2 verschidene Datenbanken... Einmal 120.000 Datensätze und
einmal 70.800 Datensätze ca. 77 Millisekunden!

Das wäre aber kein fairer Vergleich. Die Zeit zum Öffnen der ADOTable muss natürlich eingerechnet werden.
Ebenso muss die Datenbank frisch geöffnet worden sein, denn wenn die Daten mal im RAM (Cache) sind,
geht alles viel schneller.

Nee, isser wirklich nicht.

Wie wurde denn getestet? Etwa so?

markieren

Delphi-Quellcode:

...
  ADOTabel1.open;
  T := GetTickCount;
  For i:=1 to 20000000 do v := ADOTable1.RecordCount;
  ShowMessage (Format('Wow, wie schnell: %d ticks', [GetTickCount - t]));
...

Da Recordcount nur bei einer geöffneten Tabelle funktioniert, muss ja wohl logischerweise die Tabelle irgendwie geöffnet sein. Ergo muss man das mitberücksichtigen, ausgenommen, Du willst wissen, wie viele Records deine geöffnete Tabelle hat, dann natürlich nicht. Is ja logisch.

Wenn ich das mit Access mache (13.000 Records), ist das Verhältnis zwischen Recordcount und 'select count (*)' etwa 2:1, der Aufruf via Recordcount dauert also etwa doppelt so lange. Dabei hatte ich zum Testen die Tabelle vorher geöffnet, insofern war sie schon im Cache.

Bei einem SQL-Server sieht die Sache irgendwie ein klein wenig anders aus: 100:1 (Recordcount ggü. Select count (*)) bei serverseitigem und 10:1 bei clientseitigem Cursor. Is ja auch logisch, weil der Server im anderen Zimmer steht. Das sind 5 Meter + Wand (Beton). Das dauert .