TDBGrid Summenspalte führen

[af0815]

Ich habe ein DBGrid welches aus einer DB (ua. SQLite3) Daten bezieht. In einer Spalte sind Werte (positiv und negativ) die Aufsummiert gehören und zwar je Reihe.

Beispiel ist ein Kontoauszug, wo ich Buchungszeilen habe und am Ende jeder Zeile die Balance des Kontos sehe.

Muß ich das programmtechnisch per Cursor (DB) oder durch iterieren durch das Grid lösen oder kann ich das am Dataset oder Grid direkt (einfach) lösen?

af

[Michl]

In der Hoffnung, dass ich die Frage richtig verstanden habe: Mir sagt mein Bauchgefühl, dass die Abfrage (Summierung) per SQL schneller (da von Datenbank direkt bezogen) schneller aber weniger flexibel ist. Somit ist die Frage eher eine des persönlichen Geschmacks oder Anspruchs. Ich würde Abfragen mittels "SQL direkt" bevorzugen.

[af0815]

Anbei ein Beispiel wie es aussehen soll.

[Christian]

Mein Bauchgefühl sagt das Gegenteil. Der Server braucht die selbe Rechenkapazität dafür wenns richtig implementiert ist zudem muss die Abfrage und die Antwort übers Netzwerk. Warum sollte das aufm Server schneller sein ? Weiterhin blockiert man auf den Server dabei resourcen die andere Nutzer vllt sinnvoller verwenden könnten.

[af0815]

... Mir sagt mein Bauchgefühl, dass die Abfrage (Summierung) per SQL schneller...

Kein Thema, nur die Summenspalte kann ich nicht auf SQL-Ebene abhandeln (ausser serverseitiges Programmieren). Da die Datenbank auf Desktop beschränkt sein soll und womöglich SQL-Dialektunabhängig sein soll, ist das für mich aktuell nicht so zu machen. Ich habe kein Problem mit Datenbanken, Datenmengen etc. nur mit der (selbstgestellten) Aufgabe. Ist also KEINE Aufgabe für die Schule

Momentan ist mein Ansatz, das ganze doch nicht mit DBGrid zu machen sondern nur mit Grid und das Datenset programmtechnisch zu befüllen und dabei die Summenspalte gleich mitzuberechnen.

[wp_xyz]

Dieses Beispiel dürfte ähnlich zu deinem Problem sein: http://www.office-loesung.de/ftopic305290_0_0_asc.php
Allerdings wird diese SQL-Lösung performance-mäßig weit hinter einer lokalen Berechnung zurückbleiben.

[af0815]

Korrekt, bin momentan bei folgenden Statement gelandet. Halt das übliche mit einer Selbstverknüpfung.

Code: Alles auswählen

 
SELECT v.TransID,
             v.TransCode,
             v.TransDate,
             v.STATUS,
             v.Notes,
             v.ToTransAmount,
             v.CategID,
             v.Transactionnumber,
             v.rowid,
             SUM(a.ToTransAmount) AS RunningTotal
             FROM CHECKINGACCOUNT_V1 v CROSS JOIN CHECKINGACCOUNT_V1 a
             WHERE (a.rowid <= v.rowid)
             GROUP BY v.rowid, v.ToTransAmount
             ORDER BY  v.rowid , v.ToTransAmount  
 

Macht mir aber momentan Ärger mit dem Speicher. Ist auch vollkommen klar wieso es Ärger mit der Performance UND dem Speicher gibt. Der Ansatz ist lieb aber langfristig unbrauchbar. Das war mir aber vorher schon klar. Wird also NICHT weiterverfolgt.