DBGrid vs. ListView

[magic.christel]

Hallo zusammen,

spricht eigentlich etwas dagegen, wenn man statt einer DBGrid eine ListView verwendet in die das SQL-Ergebnis geschrieben wird?

Die DBGrid ist in den Delphi Version 2-5 sehr buggy (z.B. die Scrollbar), so dass ich lieber die ListView verwende.

Auch von der Performance her, sehe ich (bei bisher nur kleinen Tests) keinen Nachteil.

Ich vermute, dass ein DBGrid doch auch nur das SQL-Ergebnis ausliest und in eine StringGrid schreibt, oder?

Gibt es irgendetwas zu bedenken, wenn ich die ListView verwende? Da ich das DBGrid bisher immer nur als ReadOnly verwendet habe, geht mir doch keine Funktionalität verloren? Und auch dieses könnte man bestimmt durch ein "OnClick" händisch erledigen, oder?

Danke

Christian

[blablab]

Das DBGrid ist halt sehr schnell. Das greift direkt auf die Tabelle zu und liest nur die Zeilen aus, die gerade angezeigt werden.
Wenn du ein TListView benutzt, musst du immer alle einträge der Tabelle einlesen und eben große datenmengen in den Speicher befördern.

ich würde sagen, bis zu einer datenmenge von ca 1000 zeilen ist das noch ganz in ornung.
da dauert das in den speicher laden noch nicht so lange und du kannst noch ziemlich gut mit den einträgen arbeiten.
Sobald du aber mehr als 1000 zeilen in die listview einfügen willst, würde ich dir dringend empfehlen das DBGrid zu benutzen! mit dem dbgrid kannst du locker 100.000 einträge verwalten und gut damit arbeiten, ohne probleme mit der geschwindigkeit zu bekommen.

[Bernhard Geyer]

Zitat:

Zitat von magic.christel

Die DBGrid ist in den Delphi Version 2-5 sehr buggy (z.B. die Scrollbar), so dass ich lieber die ListView verwende.

Meinst Du damit das die Scrollbar nur 3 Positionen kenn: Anfang/Mitte/Ende. Dies ist keine Fehler der Scrollbar sondern ein Einschränkung wenn man Serverseitige Curser verwendet bzw. Zugriffskomponenten die den Wert von RecordCount nicht sofort gültig haben.

Zitat:

Zitat von magic.christel

Auch von der Performance her, sehe ich (bei bisher nur kleinen Tests) keinen Nachteil.
Ich vermute, dass ein DBGrid doch auch nur das SQL-Ergebnis ausliest und in eine StringGrid schreibt, oder?

Das Grid ist schon etwas intelligenter. Es läuft i.d.R. in einem sogenannten Page-Modus und fordert (bei Serverseitigen Curser) nur soviel Daten an entsprechend der Scrollposition. Im Idealfall z.B. wenn Du 10.000 Datensätze mit Serverseitigen Curser hast nur 20 Datensätz wenn nur dies Dargestellt werden. Aber Vorsicht :warn: : Der SQL-Server muss die Ergebnismenge u.U. schon komplett in eine Temporärtabelle kopieren (MS-SQL-Server, Server-Last).

Selbst haben wir unser größere Anwendung vom DB-Grid befreit und Arbeiten immer mit Limited-Abfragen (1 Mio.Datensätze anzeigen ist nunmal nicht gerade sinnvoll). Damit kommen wird schnell zur Anzeige und belasten den Server nicht übermäßig. Auch haben wir als Nebeneffekt die DB-Abhängigkeiten auch wieder los die manchmal bis ins Grid durchgeschlagen ist (Unicode-Support).

[marabu]

Hi folks,

wie aktuell doch manche Themen auch nach drei Jahren noch sind. Aus meinen Projekten ist das DBGrid schon lange verschwunden. Seit MS mit W95 die damals neuen common controls ListView und TreeView eingeführt hat, arbeiten die virtuellen Varianten dieser Komponenten zur Zufriedenheit meiner Anwender. Die vertraute Oberfläche sorgt für spontane Akzeptanz. Die Auswahlmöglichkeit unter den verschiedenen ViewStyles wird allgemein begrüßt.

Neujahrsgrüße vom marabu

[blablab]

Hi,

ja, das stimmt! Das DBGrid ist wirklich ungewohnt und deshalb werden wohl die meisten benutzer für TListView sprechen.
Jedoch bin ich der Meinung, dass viele Operationen mit dem DBGrid viel einfacher (und auch schneller) gehn!

Zum Beispiel habe ich versucht die Spalten einer TListView zu vertauschen. Das geht auch ganz gut. Doch sobald ich dann eine neue Spalte hinzufügen möchte, kommt es zu Problemen:
Irgendwie vertauscht er dann die einzelnen Spalten wieder so, wie sie zu Beginn waren. Dann fügt er die neue Spalte hinten an, ABER die Überschriften der einzelnen Spalten bleiben gleich.
Somit stimmen die Spalten nicht mehr mit ihren Überschriften überein.

Letztendlich habe ich mich dann für das DBGrid in meinen Programmen entschieden...

[Bernhard Geyer]

Wenn man etwas auf die Suche geht bekommt man auch DBGrids mit besserer Optik oder TListViews mit einfacherer/besserer Programmierung. Evtl. kostet es jedoch ein paar € (TElTreeStringGrid/TElDBTreeStringGrid, QuantumGrid, ...)

[Hansa]

Das Thema ist gut. Verwende auch kein DBGrid, allerdings hauptsächlich, weil es zu unflexibel ist. Nur wieso kommt ihr auf ListView und nicht auf ein normales Stringgrid ? Im Endeffekt macht das nicht mehr Arbeit, wie das DBGrid. Werden spezielle Eigenschaften gefordert, dann behaupte ich sogar, daß ein Programm mit Stringgrid schneller zu entwickeln ist, als mit einem DBGrid, was mühsam angepaßt werden muß. Bei den Spezialgrids Quantum usw. schlägt auch massiv zu Buche, daß man die erst mal kennen muß (Tricks und auch Bugs).

Ausführungsgeschwindigkeit : da gibt es einen unscheinbaren, aber fast nicht zu glaubenden Effekt zu beobachten. Wird das Stringgrid Zeile für Zeile dargestellt, oder aber im Hintergrund das macht einen Faktor von mind. 100 (bei sinnvollen Datenmengen) aus. Und das ist kein Witz ! Wir hatten hier Testreihen gemacht. Bei 50.000 Datensätze aus DB gelesen (wer macht sowas ?) und im Stringgrid dargestellt. Dauer ca. 1 Sek. Vielleicht warens auch 5 oder 10. Dasselbe mit direkter Darstellung : ca. 1 St. :shock: Und das war kein ganz simples Stringgrid. Nur mal als Anregung. Zahlen ohne Gewähr. :mrgreen: Aber die Größenordnung des Unterschiedes (also ungewohnte Warterei) war echt sehr verblüffend. :shock:

[Bernhard Geyer]

Zitat:

Zitat von Hansa

Das Thema ist gut. Verwende auch kein DBGrid, allerdings hauptsächlich, weil es zu unflexibel ist. Nur wieso kommt ihr auf ListView und nicht auf ein normales Stringgrid ?

Ich verwende die Grids vom ElPack. Die sind sozusagend Grid und ListView in einem.

Zitat:

Zitat von Hansa

Im Endeffekt macht das nicht mehr Arbeit, wie das DBGrid. Werden spezielle Eigenschaften gefordert, dann behaupte ich sogar, daß ein Programm mit Stringgrid schneller zu entwickeln ist, als mit einem DBGrid, was mühsam angepaßt werden muß. Bei den Spezialgrids Quantum usw. schlägt auch massiv zu Buche, daß man die erst mal kennen muß (Tricks und auch Bugs).

Das stimmt. Jedes Grid hat seine Eigenheiten. Wird selbst haben ein größeres Projekt auf ElTree(StringGrid) umgestellt und haben dabei 2-3 andere Grids ersetzt. ElPack deshalb weil wir Unicode benötigten und kein anderes das so kann.

Zitat:

Zitat von Hansa

Ausführungsgeschwindigkeit : da gibt es einen unscheinbaren, aber fast nicht zu glaubenden Effekt zu beobachten. Wird das Stringgrid Zeile für Zeile dargestellt, oder aber im Hintergrund das macht einen Faktor von mind. 100 ... Aber die Größenordnung des Unterschiedes (also ungewohnte Warterei) war echt sehr verblüffend. :shock:

Wenns unbedingt sein muss: Das ElTree(StringGrid) kann auch Virtual Mode. Und damit gehts auch Ratz-Fatz. Auch im "normalen" Modus hängt es das TListView ab, da es nicht mittels Win32-API kommunizieren muss sondern Pure-Delphi ist.

[jbg]

Zitat:

Zitat von Bernhard Geyer

TElTreeStringGrid/TElDBTreeStringGrid

Die ElDOS Komponenten sind echt die besten :wall: . Heute habe ich da wieder zwei gravierende Programmierfehler in TElDBTree ausbessern dürfen. Und der Support ist auch gut: "Vererben sie halt ihre Formulare nicht, dann tritt der Fehler nicht auf". Danke. Von dem Link-Fehler mal noch gar nicht gesprochen, der auftritt, wenn ich kompiliere und ein Formular mit TElDBTree noch offen ist. Zudem sollte man das gesamte ElDOS Paket nicht mit FastMM4 und WinXP Theming kompilieren. Die vielen Speicherlecks kann man nicht derzählen ( >4000). Und zudem bekommt man da so eine tolle Exception von FastMM4, die einem erzählt dass auf bereits freigegeben Speicher zugegriffen wird. Und da die beiden Komponenten von TElCustomDBTree abgeleitet sind, teilen sie sich die Bugs.
Wenn die Komponenten nicht schon so oft in dem Projekt verwendet würden, hätte ich sie schon lange durch JVCL Komponenten ersetzt.


Ein Beispiel:

Delphi-Quellcode:

TElDBTree.Create:
FDataFields := TStringList.Create;

TElDBTree.Destroy:
FDataFields.Free;

TElDBTree.SetDataFields(Value: TStringList):
FDataFields := Value; // wie war das nochmal mit Settern für StringListen, wenn man sie selbst verwaltet?

[Bernhard Geyer]

Zitat:

Zitat von jbg

Zitat:

Zitat von Bernhard Geyer

TElTreeStringGrid/TElDBTreeStringGrid

Die ElDOS Komponenten sind echt die besten :wall: . Heute habe ich da wieder zwei gravierende Programmierfehler in TElDBTree ausbessern dürfen.

Zum TElDBTree kann ich nicht sagen. Verwende keine DB-Controls.
Und außerdem bin ich noch aktuell bei der 3.2er-Version. Werde die 4er auslassen und gleich bei der 5er wieder einsteigen.

Zitat:

Zitat von jbg

Und der Support ist auch gut: "Vererben sie halt ihre Formulare nicht, dann tritt der Fehler nicht auf". Danke.

Wer macht den sowas. :roll: Wir verwenden das TFrames-Prinzip - blos ohne Frames. Nehmen normale TForms und lassen den Inhalt "rüberschnappen". Problemlos auch bei 1 Mio. Quellzeilen.

Zitat:

Zitat von jbg

Zudem sollte man das gesamte ElDOS Paket nicht mit FastMM4 und WinXP Theming kompilieren. Die vielen Speicherlecks kann man nicht derzählen ( >4000). Und zudem bekommt man da so eine tolle Exception von FastMM4, die einem Erzählt dass auf bereits freigegeben Speicher zugegriffen wird. Und da die beiden Komponenten von TElCustomDBTree abgeleitet sind, teilen skie sich die Bugs.

Da muß wohl alle Bugs im DBTree versammelt sein. Ich selbst verwende ElPack mit FastMM4 (davor MemCheck) und (Windows, not native XP-Theming) und bekomme keine Speicherlücken. ElPack 5 (Beta) hat noch ein paar aber auch nicht die Welt.

Zitat:

Zitat von jbg

Wenn die Komponenten nicht schon so oft in dem Projekt verwendet würden, hätte ich sie schon lange durch JVCL Komponenten ersetzt.

Na ja. Ob die all das Können. Ist die Jedi nicht immer noch darüber die ganzen gespendeten Komponenten zu verdauen? Und ohne Unicode geht gar nichts.

Zitat:

Zitat von jbg

Ein Beispiel:

Delphi-Quellcode:

FDataFields := Value; // wie war das nochmal mit Settern für StringListen, wenn man sie selbst verwaltet?

Wie schon gesagt. Muß wohl alles im DBGrid versammelt sein.
Meldest du auch diese Bugs das sie behoben werden können? Ich kann mich jedenfalls nicht beschweren. Die Fehler die ich gefunden hatte waren meist komplexerer Art.