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.

[jbg]

Zitat:

Zitat von Bernhard Geyer

Wie schon gesagt. Muß wohl alles im DBGrid versammelt sein.

Das stimmt. Es ist nur alles von TElCustomDBTree abgeleitete betroffen.

Zitat:

Wer macht den sowas. Rolling Eyes Wir verwenden das TFrames-Prinzip - blos ohne Frames.

Wir haben hier mehr eigen-vererbte Formulare als von TForm-vererbte. Es ist einfach einfacher die Persistenz in einem Basis-Formular zu haben, statt in jedem einzelnen Formular. In meinen privaten Projekten nutze ich sowas normalerweise nie. Da ist TJvEmbededFormXxx und machmal auch TJvDockXxx der Ersatz. (Als JVCL Developer sollte man die Komponenten halt auch mal verwenden :lol: )

Zitat:

Ich selbst verwende ElPack mit FastMM4 (davor MemCheck) und (Windows, not native XP-Theming) und bekomme keine Speicherlücken.

Das tritt auch nur unter WinXP mit aktivierten XP-Theming auf, wenn die ElXPThemedXxx Units zuschlagen. Da wird für jedes Control ein Objekt erzeugt und beim Beenden wird der der ElPack ElThemeManager (oder wie der immer heißen mag) nicht mehr freigegeben, weil irgendwo eine Variable 0/nil liefert. FastMM4 braucht dann ca. 2 Minuten bis es Speicherleck-Dialog bringt. Den Fehler habe ich bis heute noch nicht gefunden. Da ich dieses Theming aber gar nicht brauche, weil ich ein eigenes geschrieben habe, haben wir einfach NO_ELPACK_USE_THEME_ENGINE definiert und weg sind die Lecks.

Zitat:

Ob die all das Können. Ist die Jedi nicht immer noch darüber die ganzen gespendeten Komponenten zu verdauen?

Verdaut ist das bereits, wenn auch noch ein paar überbleibsel da sind (Globus, Jans). Und wenn sie etwas nicht können, dann muss ich halt mal wieder etwas OpenSource produzieren und die Komponenten weiterentwickeln.

Zitat:

Und ohne Unicode geht gar nichts.

Das spielt bei dem Projekt sowieso keine Rolle. Zumindest hat sich noch keiner darüber beklagt, dass er die Text nicht in trad. Chinesisch lesen kann.

Zitat:

Meldest du auch diese Bugs das sie behoben werden können?

Ich weiß nicht wie es in der 5er Version aussieht. Wir habe nur Version 4.02. Aber ich nehme nicht an, dass die ihren Programmierstil (damit ist nnicht der Code-Style gemeint) geändert haben. Der gefällt mir persönlich nämlich gar nicht.

[Bernhard Geyer]

Zitat:

Zitat von jbg

Zitat:

Wer macht den sowas. Rolling Eyes Wir verwenden das TFrames-Prinzip - blos ohne Frames.

Wir haben hier mehr eigen-vererbte Formulare als von TForm-vererbte. Es ist einfach einfacher die Persistenz in einem Basis-Formular zu haben, statt in jedem einzelnen Formular. In meinen privaten Projekten nutze ich sowas normalerweise nie. Da ist TJvEmbededFormXxx und machmal auch TJvDockXxx der Ersatz. (Als JVCL Developer sollte man die Komponenten halt auch mal verwenden :lol: )

OK. Ist sinnvoll.

Zitat:

Zitat von jbg

Zitat:

Ich selbst verwende ElPack mit FastMM4 (davor MemCheck) und (Windows, not native XP-Theming) und bekomme keine Speicherlücken.

Das tritt auch nur unter WinXP mit aktivierten XP-Theming auf, wenn die ElXPThemedXxx Units zuschlagen. Da wird für jedes Control ein Objekt erzeugt und beim Beenden wird der der ElPack ElThemeManager (oder wie der immer heißen mag) nicht mehr freigegeben, weil irgendwo eine Variable 0/nil liefert. FastMM4 braucht dann ca. 2 Minuten bis es Speicherleck-Dialog bringt. Den Fehler habe ich bis heute noch nicht gefunden. Da ich dieses Theming aber gar nicht brauche, weil ich ein eigenes geschrieben habe, haben wir einfach NO_ELPACK_USE_THEME_ENGINE definiert und weg sind die Lecks.

OK. Ich verwende das native ElPack-Theming nicht. Ist auch bei komplexen Dialogen langsamer.

Zitat:

Zitat von jbg

Zitat:

Meldest du auch diese Bugs das sie behoben werden können?

Ich weiß nicht wie es in der 5er Version aussieht. Wir habe nur Version 4.02. Aber ich nehme nicht an, dass die ihren Programmierstil (damit ist nnicht der Code-Style gemeint) geändert haben. Der gefällt mir persönlich nämlich gar nicht.

Was genau meinst Du damit?

[Hansa]

Was zum Teufel sind eigen-vererbte Formulare ? :shock: Aber egal. Was ich hier lese ist ja noch schlimmer als befürchtet. Meine Erfahrung sieht so aus : es ging damals konkret lediglich (ja, es war schon noch mehr gefordert) um das Anzeigen von mehreren Artikel-Bezeichnungszeilen und zwar untereinander (1 vorhanden, auch nur eine anzeigen, bei 3 Art.-Zeilen dann 3 anzeigen, Art.-Nr. usw. natürlich nur in 1. Zeile) : Standard DBGrid 3 Wochen ohne Erfolg. Fremd-Grids : 2 Wochen getestet, kaum Besserung. Wenn da tatsächlich unbekannte Bugs gehäuft zu finden sind, dann wären wohl 2 Monate draus geworden oder gar nichts. Dann wurde ich für verrückt erklärt, weil ich der Ansicht war, daß ALLE DBgrids Scheiße sind :mrgreen: und das mit Stringgrids machen wollte. Aber sieh an, nach einer Woche war das alles perfekt, genau wie gefordert. Es gibt nur noch ein Grundgerüst für sämtliche Grids :

Delphi-Quellcode:

..
//  Variablen für Grid-Anzeige setzen. Rechtsbündig, Nachkommastellen usw.
//  OnDrawCell anpassen
..
ErmittleDaten; // baut egal welches select zusammen
sg.Hide;
ZeigePositionen;  // Anzeige im Grid, notfalls Objects für Sonderfälle bestücken
sg.Show;

Natürlich wird das alles vererbt (Objektablage). D.h. ich nehme eine inherited Form mit Grid und überschreibe hautsächlich nur diese beiden Prozeduren. Rest bleibt fast gleich. ABer es geht ja um DBGrid <-> ListView. Das hatte ich mir auch angesehen. Aber etwas, was gleichzeitig ein Baum und ein Grid sein kann, was soll das schon besonderes sein ? Nicht mal Objects hat das Ding.

[jbg]

Zitat:

Zitat von Hansa

Was zum Teufel sind eigen-vererbte Formulare ?

Das sind Formulare die nicht direkt von TForm erben. Das Wort habe ich gestern mal schnell erfunden.

[Hansa]

Zitat:

Zitat von jbg

gestern mal schnell erfunden.

:lol: Von was erben die denn dann was ?

[jbg]

Auch wenns Offtopic ist:
Z.B von TBaseForm.

Code:

TBaseForm
  TToolForm
    TToolBarForm
      TDBEditToolBarForm
        TPersonForm

[Hansa]

Ah ja. Angenommen TDBEditToolBarForm braucht eine CheckBox oben rechts und TPersonForm braucht die auch, aber unten links. Was dann ? Koordinaten von Hand eingeben ?

[jbg]

Zitat:

Zitat von Hansa

Ah ja. Angenommen TDBEditToolBarForm braucht eine CheckBox oben rechts und TPersonForm braucht die auch, aber unten links. Was dann ? Koordinaten von Hand eingeben ?

Nö. Einfach per Formdesigner nach links unten verschieben. Dafür ist das "Projektformular vererben" ja da.