DBGRID Anzahl der Datensätze anzeigen.

[Andy Nightingale]

Hallo Leute,
gibt es eine einfache Möglichkeit im DBGRID die Anzahl der geladenen Daten im Grid anzuzeigen? Momentan habe ich ein Label mit dieser Programmierung:

Code: Alles auswählen

procedure TFStickstoff.Label1Click(Sender: TObject);
begin
    Label1.Caption := Format('Anzahl Datensätze: %d', [DataSourceStickstoff.DataSet.RecordCount]);
end;                                                                                                

[af0815]

RecordCount gibt die je nach Datenbank nur zurőck, wieviele Datensátze gefeched worden sind.

siehe auch
https://lazarus-ccr.sourceforge.io/docs ... count.html
https://wiki.lazarus.freepascal.org/SqlDBHowto/de

Am besten ist es, den Server direkt mit "SELECT COUNT(*)" oder ähnlich zu fragen. Es gibt den Tip "Query.PacketRecords := -1; // <-- FetchAll" zu verwenden, nur das erzwingt, das das komplette Datenset geladen wird. Bei sicher immer kleinen Datenmengen ist das jetzt noch akzeptabel.

[Joh]

Am besten ist es, den Server direkt mit "SELECT COUNT(*)" oder ähnlich zu fragen. Es gibt den Tip "Query.PacketRecords := -1; // <-- FetchAll" zu verwenden, nur das erzwingt, das das komplette Datenset geladen wird. Bei sicher immer kleinen Datenmengen ist das jetzt noch akzeptabel.

Bei ((sicher immer kleinen Datenmengen) und (lokalen Datenbanken))...

[Andy Nightingale]

Am besten ist es, den Server direkt mit "SELECT COUNT(*)" oder ähnlich zu fragen. Es gibt den Tip "Query.PacketRecords := -1; // <-- FetchAll" zu verwenden, nur das erzwingt, das das komplette Datenset geladen wird. Bei sicher immer kleinen Datenmengen ist das jetzt noch akzeptabel.

Bei ((sicher immer kleinen Datenmengen) und (lokalen Datenbanken))...

Genau richtig erkannt...

[af0815]

lokalen Datenbanken

Man muss den Typ der Datenbank sich ansehen. Bei Dbase, FoxPro oder Access war der Recordcount das richtige MIttel der Wahl (Abgesehen, das ich eine Access und Excel Allergie berufsbedingt habe).
Bei Server Datenbanken (auch wenn sie lokal sind) sieht das anders aus, weil die Treiberschichten auf Datenmengen ausgelegt sind und nicht auf Datensätze.

Wenn du den den "SELECT COUNT(*)" verwendest, so kann der Optimizer vom SQL-Server sich die Daten optimiert zusammenstellen und liefert genaugenommen nur ein einfaches Recordset mit einer Zeile zurück. Das geht flott, meisten ist es nur ein IP-Paket. Muss der Server jetzt die kompletten Daten übertragen, so kann das im schlechtesten Fall die Netzwerklast unnötig belasten, weil Daten übertragen werden, die am Client nur gepuffert werden, genaugenommen aber nicht gebraucht werden. Brauche ich die Daten wirklich alle, so ist es besser diese geeignet abzulegen und dann die Anzahl übers Programm zu berechnen. Das schlechteste ist natürlich die Daten 2x abzurufen - einmal umd die Anzahl in Erfahrung zu bringen und einmal um sie anzuzeigen.

Ich habe da viel Lehrgeld gezahlt, über die Netzwerkverbindungen früher nach Fernost. Das ging am Anfang noch über T1 Verbindungen (https://de.wikipedia.org/wiki/Trunk_1). Viel Spass mit Datenmengen auf den Leitungen . Es ist aber aus Sicht des DB-Admins auch nicht lustig, wenn man draufkommt, das da unnötige Locks, Bandbreiten, Loads etc. am Server erzeugt werden.

[Zvoni]

Oder statt einem separaten SELECT COUNT(*) gleich im ursprünglichen SELECT mitliefern
(Beispiel aus einem meiner Programme)

Wichtig: Der Filter muss in beiden SELECTs derselbe sein. Kann sogar parametriert werden

Code: Alles auswählen

select * from tbl_country_provider_zone As B
inner join 
(select count(*) as Cnt from tbl_country_provider_zone where Country_ID=1) as A on 1=1
where B.Country_ID=1

Damit wird die Anzahl Zeilen bei jedem Datensatz geliefert, und du brauchst nur die Spalte im ersten Datensatz auszulesen