fkCalculated Feld - SQLITE3 Datenbank - Änderungen gehen verloren...

[Meridian]

Moin zusammen,

ich bin's wieder, der Hobbyist.

Habe festgestell, dass bei Verwendung eines Datenbank-Feldes als fkCalculated (und nur dann) die Änderungen (in allen anderen Feldern) nach einem Refresh nicht übernommen werden.
Es läuft ohne Probleme, wenn ich kein fkCalculated - Feld verwende.

Was muss ich bei fkCalculated noch beachten, was dieses Verhalten vielleicht lösen kann?

Gruß aus Niedersachsen...

[charlytango]

Jetzt gibt es hier sicher Berufenere für dieses Thema.

Aber auf Fragestellungen dieser Art könnten Antworten der Art "Meine Glaskugel ist gerade beim Service" kommen.
Die Frage wäre, WIE und in welchem Control du das fkCalculated Feld verwendest.
Und dann hilft es ungemein wenn es ein kleines Testprojekt gibt wo man das Problem nachvollziehen und dann auch testen kann.

Bei DB-Anwendungen ist das wegen der DB etwas aufwendiger (das erste mal), aber mit SQLite kannst du eine Test-DB (also das SQLite File) mit Rumpfdaten verwenden, dann ist es wieder einfacher

[Zvoni]

Jepp. Meine Glaskugel ist gerade in der Inspektion.

Immer wenn ich was mit Datenbank und Calculated sehe, schrillen alle Alarmglocken bei mir.

Also: Wie sieht die Tabelle aus, wie sind die Spalten/Felder definiert, wie holst du die Daten ab (SQL-SELECT-Statement)?
Und was änderst du wo, was dann wohin nicht "durchvererbt" wird?

[af0815]

Also: Wie sieht die Tabelle aus, wie sind die Spalten/Felder definiert, wie holst du die Daten ab (SQL-SELECT-Statament)?
Und was änderst du wo, was dann wohin nicht "durchvererbt" wird?

Zusatzfrage: Kommen die Änderungen auch in der DB an ?

Weil bei Calculated brauchst du ja eine Basis von den du die Werte weg berechnest. Werteänderungen im Calculated Feld schlagen ohne spezielle Behandlung nicht in die ursprüngliche Datenmenge zurück. Daher ohne spezielle Behandlung ist ein calculatet Feld immer als ReadOnly zu betrachten. (Ich vermute das sind die Alarmglocken von Zvoni)

[Zvoni]

Also: Wie sieht die Tabelle aus, wie sind die Spalten/Felder definiert, wie holst du die Daten ab (SQL-SELECT-Statament)?
Und was änderst du wo, was dann wohin nicht "durchvererbt" wird?

Zusatzfrage: Kommen die Änderungen auch in der DB an ?

Weil bei Calculated brauchst du ja eine Basis von den du die Werte weg berechnest. Werteänderungen im Calculated Feld schlagen ohne spezielle Behandlung nicht in die ursprüngliche Datenmenge zurück. Daher ohne spezielle Behandlung ist ein calculatet Feld immer als ReadOnly zu betrachten. (Ich vermute das sind die Alarmglocken von Zvoni)

Jepp.
Wobei ich auch gerade noch mal charlies Post genauer durchgelesen habe: Welches Control wird verwendet, um was zu "ändern"?

[Zvoni]

Zusammenfassend (Beispielhaft)
Du hast 2 Felder die du aus der DB holst, nennen wir sie "Preis" und "Menge"
Du hast 3 Spalten (DBGrid) oder Textboxen (DBEdit), wo die dritte dann "berechnet" wird (Preis * Menge)

Was wird jetzt nicht durchvererbt, wenn du wo was änderst?

[charlytango]

jetzt haben wir ihn geschockt

[Meridian]

jetzt haben wir ihn geschockt

nein, ihr habt mich nicht geschockt. Hatte nur zu tun.

[Meridian]

Asche auf mein Haupt.
Ja, ihr habt ja Recht. Etwas mehr Information wären gut gewesen...

Also hier im Anhang mein Demoprogramm. In der oberen "grünen" Tabelle werden Änderungen nach Post und Refresh übernommen. Hier habe ich keines der Felder als fkCalculated deklariert.

In der unteren "weißen" Tabelle ist das feld G_Preis als calculated gestzt und der G_Preis wird errechnet (G_Preis := E_Preis * Bestand)

Hoffe, dass ihr damit etwas anfangen könnt.

Vielen Dank an alle, die sich gedanken mach und eventuell testen.

[wp_xyz]

Evtl musst du SQL-Ausdrücke für Update, Insert, Refresh angeben (TSQLQuery.UpdateSQL, etc), in denen das berechnete Feld nicht enthalten ist, denn dieses kann nicht beschrieben werden.

[charlytango]

Warum zum Geier wettere ich ewiglich gegen 'SELECT *' ??

Das ist nicht nur schlechter Stil sondern bringt heftig Probleme.
Im Ablauf, im Code, in der Performance etc.
Und weil wir gerade dabei sind, eine SQL Anbindung ohne Möglichkeit zum Monitoring (also was kommt vom Server und was wird hin geschickt) ist Murks zum Programmieren.

Wie wärs denn, wenn du ein sauberes SELECT in tbLagerB verwendest?
Das alleine würde das Update-Problem schon lösen. Probier es aus.

Und wenn du es besonders schön machen willst, dann setze den Updatemode auf upWhereKeyOnly und trag ein sauberes Update Statement ein, wie es wp_xyz vorgeschlagen hat

Und weil Ostern kommt gibts auch Geschenke

Code: Alles auswählen

    tbLagerB.SQL.Text := 'SELECT ID,Artikel_Nr,Hersteller_Nr,Hersteller,Bezeichnung,Warengruppe,Bestand,Lagerort,E_Preis FROM LAGERVERWALTUNG';


    tbLagerB.UpdateSQL.Text:= 'UPDATE LAGERVERWALTUNG '+
                              'SET ' +
                              'Artikel_Nr = :Artikel_Nr, Hersteller_Nr = :Hersteller_Nr, Hersteller = :Hersteller, Bezeichnung = :Bezeichnung, '+
                              'Warengruppe = :Warengruppe, Bestand = :Bestand, Lagerort = :Lagerort, E_Preis = :E_Preis '+
                              'WHERE ID = :ID';

[Maddias]

Habe festgestell, dass bei Verwendung eines Datenbank-Feldes als fkCalculated (und nur dann) die Änderungen (in allen anderen Feldern) nach einem Refresh nicht übernommen werden.

Hallo Meridian,

ein berechnetes Feld braucht keine Spalte in der Datenbank-Tablle! Du kannst die Spalte G_Preis löschen in beiden SQLite DBs. Sie ist überflüssig, weil die Daten zur Berechnung schon in der Datenbank gespeichert sind (Bestand & E_Preis),

Auch würde ich die Spaltenbreite in der statischen Feldliste setzen als DisplayWidth. Dort ist sie aber nicht in Pixel sondern in Anzahl Buchstaben angegeben.

Salut,
Mathias

[Zvoni]

Habe festgestell, dass bei Verwendung eines Datenbank-Feldes als fkCalculated (und nur dann) die Änderungen (in allen anderen Feldern) nach einem Refresh nicht übernommen werden.

Hallo Meridian,

ein berechnetes Feld braucht keine Spalte in der Datenbank-Tablle! Du kannst die Spalte G_Preis löschen in beiden SQLite DBs. Sie ist überflüssig, weil die Daten zur Berechnung schon in der Datenbank gespeichert sind (Bestand & E_Preis),

Auch würde ich die Spaltenbreite in der statischen Feldliste setzen als DisplayWidth. Dort ist sie aber nicht in Pixel sondern in Anzahl Buchstaben angegeben.

Salut,
Mathias

Muss ich widersprechen.
Wieso etwas im Frontend machen, wenn es die Datenbank selbst kann (und meist besser)?

Tabellenerstellung ändern:

Code: Alles auswählen

s := 'CREATE TABLE LAGERVERWALTUNG(';
  s := s + ' ID INTEGER PRIMARY KEY AUTOINCREMENT,';
  s := s + ' Artikel_Nr VARCHAR(15),';  //Hier fehlt NON NULL und UNIQUE --> Eine Artikel_Nr darf nicht leer sein, und muss eimalig sein
  s := s + ' Hersteller_Nr VARCHAR(15),';
  s := s + ' Hersteller VARCHAR(20),';
  s := s + ' Bezeichnung VARCHAR(40),';  //Hier NON NULL, ggfs. sogar noch dazu UNIQUE
  s := s + ' Warengruppe VARCHAR(30),';
  s := s + ' Bestand Integer,';  //DEFAULT 0
  s := s + ' Lagerort VARCHAR(15),';
  s := s + ' E_Preis REAL,';
  s := s + ' G_Preis REAL GENERATED ALWAYS AS (Bestand*E_Preis) STORED';  //HIER!!!
  s := s + ');';

Anstatt STORED kann man auch VIRTUAL nehmen.
Unterschied: STORED wird das Feld bei einem INSERT/UPDATE beschrieben, und braucht auch physisch Platz in der Datenbank/Platte.
VIRTUAL wird immer bei einem SELECT neu berechnet. --> ist vom Prinzip her dasselbe wie ein "SELECT ..... (Bestand*E_Preis) As G_Preis FROM....."
Der Unterschied ist, dass du bei einer GENERATED COLUMN einen expliziten Datentyp angeben kannst.
Was man wann nimmt musst du selbst wissen.
Hast du 1 Million Datensätze, ist STORED besser, weil nur "einmal" berechnet wird (Beim INSERT/UPDATE)
Hast du 1 Million Datensätze und machst nen SELECT ohne LIMIT wird bei VIRTUAL auch 1 Million mal neu gerechnet.
Grundsätzlich: "G_Preis" verhält sich wie eine reguläre Spalte einer Tabelle, aber eben , dass du nichts machen musst um sie zu "berechnen"

NotaBene: Du wirst NIEMALS ein INSERT/UPDATE auf die Spalte "G_Preis" selbst machen.
"G_Preis" (bei STORED) wird IMMER neu berechnet, wenn du einen INSERT/UPDATE auf die Tabelle machst.
Also ein "INSERT INTO Tabelle1(Spalten OHNE G_preis) VALUES(....)" wird IMMER die Spalte "G_Preis" neu berechnen
Ein "UPDATE Tabelle1 SET Bestand=2000 WHERE ID=42" wird IMMER die Spalte "G_Preis" neu berechnen

Weiter im Text: Ich würde mir mal Gedanken darüber machen, welche Spalten NON NULL und/oder UNIQUE sein sollen (Artikel_Nr und/oder Bezeichnung springt mir sofort ins Auge).
Desweiteren: Bestand sollte einen DEFAULT-Wert von 0 bekommen, ansonsten bekommst du Datenbank-NULLs.

Warum hacke ich darauf rum? Ja, du wirst wahrscheinlich argumentieren "Das mache ich alles aus meinem Frontend"
"Ja, und? Ich nehm dann DB-Browser for SQLite, öffne die Datenbanken ausserhalb deiner Lazarus-App, und zerlege das ganze Ding"

Ändere die Datenbank wie oben ab, wirf die zwei OnCalcFields-Prozeduren in die Tonne, und Feuer frei.
Mit obiger Struktur bist du noch immer in deinem Design, und musst nicht viel ändern.

Oh, und was Charly gesagt hat: SELECT * FROM ist ne tickende Zeitbombe

Und das AUTOINCREMENT brauchst auch nicht. In die Tonne damit. Ist bei SQLite nur unnötiger Overhead.

[Maddias]

Hallo Zvoni,

selbstverständlich kann man eine Spalte auch auf der Datenbank-Ebene berechnen. Die Datenbank speichert dann diese Spalte nicht aber zeigt den berechneten Wert bei einem SELECT Kommando an.

Das Problem der Berechnung in der Datenbank sind Änderungen im Front-End. Wenn der Bestand oder der E_Preis geändert werden wird erst nach einem Post mit Refresh der neu berechnete Wert angezeigt. Natürlich kann man die gleiche Formel auch nochmal im Front-End berechnen, in der Spalte speichern und der Spalte mitteilen, daß sie nicht zum Umfang der Update-Spalten gehört. Dann habe ich aber die Formel in beiden Schichten der Anwendung (Datenbank & Front-End) berechnet und sollte sich die Formel ändern, so muß ich beide Schichten anpassen. Dies widerspricht ganz klar dem DRY-Prinzip.

Salut,
Mathias

[Zvoni]

Hallo Zvoni,

selbstverständlich kann man eine Spalte auch auf der Datenbank-Ebene berechnen. Die Datenbank speichert dann diese Spalte nicht aber zeigt den berechneten Wert bei einem SELECT Kommando an.

Das Problem der Berechnung in der Datenbank sind Änderungen im Front-End. Wenn der Bestand oder der E_Preis geändert werden wird erst nach einem Post mit Refresh der neu berechnete Wert angezeigt. Natürlich kann man die gleiche Formel auch nochmal im Front-End berechnen, in der Spalte speichern und der Spalte mitteilen, daß sie nicht zum Umfang der Update-Spalten gehört. Dann habe ich aber die Formel in beiden Schichten der Anwendung (Datenbank & Front-End) berechnet und sollte sich die Formel ändern, so muß ich beide Schichten anpassen. Dies widerspricht ganz klar dem DRY-Prinzip.

Salut,
Mathias

Siehe meine Ausführung oben zum Unterschied zwischen STORED und VIRTUAL.
Wenn er Bestand oder E_Preis ändert, kommt er eh nicht an einem Post vorbei.
Inwieweit er jetzt dann noch ein Refresh braucht, kann ich nicht sagen, da ich keine DB-gebundenen Controls verwende

EDIT: Nochmal zum CREATE TABLE
Du verwendest VARCHAR(XX)
Denk dran: SQLite akzeptiert das, und das (XX) wird dann auch als Grösse von sqldb ausgelesen, und den entsprechenden Feldern des Dataset zugewiesen
ABER: SQLite hindert dich nicht daran, bei einem VARCHAR(15)-Feld einen Text mit Länge 100 einzugeben!
Um das wirklich zu forcieren fehlen CONSTRAINTS (und die sind einfach --> Stichwort CHECK CONSTRAINTS).

Weiter mit CREATE TABLE: Du verwendest nicht die Option STRICT.
Bedeutet: SQLite selbst wird dich nicht daran hindern im Feld "Bestand" (Ist INTEGER) einen Text einzugeben!
Wer es nicht glaubt möge es probieren....