TDBF und Einfügen von Datensätzen ?

[PeterS]

Hallo zusammen,

ich habe mir ein Code-Beispiel aus dem Netz zusammen gebaut,
und - weil ich es so brauchen kann - in ein TFrame gepackt. Siehe Anhang.
.

Screenshot.png (21.31 KiB) 2460 mal betrachtet

.
Nun wird im Beispiel-Code die "erste Spalte" von TDBF automatisch gefüllt, mit

Code: Alles auswählen

FieldDefs.Add( 'ID', ftAutoInc, 0, True);

Kann man trotzdem Datensätze einfügen ?
Wird dann diese erste Spalte automatisch "upgedatet" ?

[wp_xyz]

ftAutoInc bedeutet, dass der Wert in der ID-Spalte automatisch erhöht wird, du musst (kannst) diesem Feld keinen Wert zuweisen. Wenn du einen neuen Record erzeugst, dann wird er entsprechend dem aktuellen Index im Grid einsortiert. Da, lt deinem Code, das Feld ID als Primär-Index dient, erscheint der neue Record also immer am Ende. Übrigens: auch wenn du einen Record irgendwo in der Mitte löschst, wird die Lücke in der ID-Abfolge nicht aufgefüllt.

[Zvoni]

Prinzipell (Hat nix mit DBF zu tun):
Solche "surrogate" Primary Keys würde ich nie (oder zumindest nur als ReadOnly) irgendwo anzeigen.
Wie ich in deiner Form sehe, hast du ein ORDER BY ID
Das ergibt in den absolut seltensten Fällen Sinn
(Es geht hier auch ein wenig um "Usability" einer Form gegenüber dem User).

Prinzipell gilt auch für AutoInc PrimaryKeys, dass man für diese in einem INSERT oder UPDATE einen Wert vorgeben kann.
Sie unterliegen aber (oder zumindest sollten) strengsten Constraints, welche HOFFENTLICH vom DBMS selbst schon vorgegeben werden.

[PeterS]

Ich muss vorweg sagen, ich habe das Code-Beispiel erstmal unkritisch fast unverändert übernommen.

ftAutoInc bedeutet, dass der Wert in der ID-Spalte automatisch erhöht wird, du musst (kannst) diesem Feld keinen Wert zuweisen.

Hab ich gesehen, das ergibt sich aus dem Beispiel-Code.

Wenn du einen neuen Record erzeugst, dann wird er entsprechend dem aktuellen Index im Grid einsortiert. Da, lt deinem Code, das Feld ID als Primär-Index dient, erscheint der neue Record also immer am Ende. Übrigens: auch wenn du einen Record irgendwo in der Mitte löschst, wird die Lücke in der ID-Abfolge nicht aufgefüllt.

Ich hatte das ID Feld erstmal drin gelassen weil ich in meinem persönlichen Code ein TDateTime Feld eingefügt habe.
Und das läßt sich - laut Lazarus Fehlermeldung beim compilieren - nicht indexieren.

Ich überlege gerade ob ich einfach ein Integer-Feld mit TDate mache - Integer läßt sich ja indexieren.
Wäre aber dann redundanter Datenmüll in Bezug auf das von mir eingeführte TDateTime Feld


Zur Erklärung: in meiner Datenbank schreibe ich 1x täglich den "Endstand" meiner Meßwerte in die Datenbank.

[Zvoni]

Zur Erklärung: in meiner Datenbank schreibe ich 1x täglich den "Endstand" meiner Meßwerte in die Datenbank.

Das heisst, du hast ein eindeutiges Tagesdatum pro Zeile?
Übrigens: Anstatt TDateTime (Was sich nicht indexieren lässt), wie wäre es mit UNIXEPOCH? Ist ein Integer.....

Denk dran: Wie du eine Information ANZEIGST hat nichts mit zu tun, wie du sie SPEICHERST

[charlytango]

Nur wieder mal meine 2 cents...

Als jemand der etliche Jahre mit DBF Programmierung auf dem Tacho hat (auch große Systeme mit Compound Indizes und mehr als 1 Mio Records pro Tabelle).

DBF kann schon was, ist aber heutzutage etwas aus der Zeit gefallen.

Ich empfehle, SQLite zu benutzen. Auch wenn diese Datenbank schräge Eigenschaften hat, halte ich diesen Ansatz doch für ausbaufähiger.
Gleich mit SQL zu beginnen bringt IMHO Vorteile. Und eine spätere Migration auf andere SQL Datenbanken ist dann im Aufwand übersichtlich.

[Zvoni]

Nur wieder mal meine 2 cents...

Als jemand der etliche Jahre mit DBF Programmierung auf dem Tacho hat (auch große Systeme mit Compound Indizes und mehr als 1 Mio Records pro Tabelle).

DBF kann schon was, ist aber heutzutage etwas aus der Zeit gefallen.

Ich empfehle, SQLite zu benutzen. Auch wenn diese Datenbank schräge Eigenschaften hat, halte ich diesen Ansatz doch für ausbaufähiger.
Gleich mit SQL zu beginnen bringt IMHO Vorteile. Und eine spätere Migration auf andere SQL Datenbanken ist dann im Aufwand übersichtlich.

Hallelujah. Preiset den Herrn...

[PeterS]

Denk dran: Wie du eine Information ANZEIGST hat nichts mit zu tun, wie du sie SPEICHERST

Jep - habe ich gestern schon herausgefunden und umgesetzt.
Statt der nativen Werte in der DB - z.B. Watt-Stunden - werden kWh angezeigt, mit einer Nachkomma-Stelle.

Code: Alles auswählen

procedure TFrameDbaseControl.ClientDataSet1fFirstGetText(Sender: TField; var aText: string;
  DisplayText: Boolean);
begin
  try
    { Dynamically display the contents of the fFirst field into the Label. }
    aText:= FloatToStrF( Sender.AsInteger / 1000, ffnumber, 1, 1) +' kWh';
  except
    { Ensure Text remains the same. }
    aText:= IntToStr( Sender.AsInteger);
  end;
end;    

Das heisst, du hast ein eindeutiges Tagesdatum pro Zeile?
Übrigens: Anstatt TDateTime (Was sich nicht indexieren lässt), wie wäre es mit UNIXEPOCH? Ist ein Integer.....

Ja, Datum + Uhrzeit "letzter Daten-Input". Also konkret z.B. 2024-09-20 23:59:320

UNIXEPOCH - muss ich mich mit befassen - es gibt ja etliche Diskussions-Threads zum Thema TDateTime <=> andere Datum/Zeit-Formate.
Nicht daß ich da in eine Falle laufe ..

[PeterS]

Nur wieder mal meine 2 cents...
Als jemand der etliche Jahre mit DBF Programmierung auf dem Tacho hat (auch große Systeme mit Compound Indizes und mehr als 1 Mio Records pro Tabelle).
DBF kann schon was, ist aber heutzutage etwas aus der Zeit gefallen.
Ich empfehle, SQLite zu benutzen. Auch wenn diese Datenbank schräge Eigenschaften hat, halte ich diesen Ansatz doch für ausbaufähiger.
Gleich mit SQL zu beginnen bringt IMHO Vorteile. Und eine spätere Migration auf andere SQL Datenbanken ist dann im Aufwand übersichtlich.

Mir ist völlig klar daß das DBF Format "aus der Zeit gefallen ist".
Bei derzeit geplanten 365 Datensätzen pro Jahr = 1 Datensatz pro Tag halte ich das für vertretbar.

Um wieviel MB wird denn eine EXE-Datei "aufgeblasen" wenn man
eine echte, moderne (SQL ?) Datenbank-Implementierung an ein Lazarus-Projekt "dranhängt" ?

REM: ich bin ein Freund des KISS-Prinzips (= Keep It Simple, Stupid)

[PeterS]

Anstatt TDateTime (Was sich nicht indexieren lässt), wie wäre es mit UNIXEPOCH? Ist ein Integer.....

Okay .. also einfach vor dem Schreiben / Lesen in die DBF umwandeln mit

https://www.freepascal.org/docs-html/rt ... ounix.html
https://www.freepascal.org/docs-html/rt ... etime.html

???

[Sieben]

Ja, Datum + Uhrzeit "letzter Daten-Input". Also konkret z.B. 2024-09-20 23:59:320

Ich würde das - genau so wie in deinem Beispiel - im Format ISO8601 in einem Textfeld speichern - ist indexierbar und jederzeit problemlos lesbar, auch mit externen Tools.

Um wieviel MB wird denn eine EXE-Datei "aufgeblasen" wenn man eine echte, moderne (SQL ?) Datenbank-Implementierung an ein Lazarus-Projekt "dranhängt" ?

Bei SQLite minimal, du brauchst nur einmalig die DLL im entsprechenden Systemverzeichnis und kannst dann in jeder Anwendung mit den entsprechenden Komponenten darauf zugreifen.

[PeterS]

Um wieviel MB wird denn eine EXE-Datei "aufgeblasen" wenn man eine echte, moderne (SQL ?) Datenbank-Implementierung an ein Lazarus-Projekt "dranhängt" ?

Bei SQLite minimal, du brauchst nur einmalig die DLL im entsprechenden Systemverzeichnis und kannst dann in jeder Anwendung mit den entsprechenden Komponenten darauf zugreifen.

Okay, das ist nicht so gut für eine "Portable App".
Das bedeutet, ich müßte die DLL mitschleppen.
Sowas würde ich gerne vermeiden.

[Zvoni]

Um wieviel MB wird denn eine EXE-Datei "aufgeblasen" wenn man eine echte, moderne (SQL ?) Datenbank-Implementierung an ein Lazarus-Projekt "dranhängt" ?

Bei SQLite minimal, du brauchst nur einmalig die DLL im entsprechenden Systemverzeichnis und kannst dann in jeder Anwendung mit den entsprechenden Komponenten darauf zugreifen.

Okay, das ist nicht so gut für eine "Portable App".
Das bedeutet, ich müßte die DLL mitschleppen.
Sowas würde ich gerne vermeiden.

Wobei es möglich ist, entweder sqlite komplett statisch einzubinden (wobei ich noch nirgends ein funktionierendes Beispiel gesehen habe),
oder die sqlite3.dll als Ressource in die EXE hinein zu kompilieren.
Ablauf dann wie folgt:
Programm startet
Check ob sqlite3.dll dort ist, wo es sein soll (neben der EXE oder ggfs. Unterordner)
Falls nein, extrahiere die DLL aus der Ressource, und speicher sie eben dort ab
Falls ja.....
Feuer frei

[PeterS]

Wobei es möglich ist, entweder sqlite komplett statisch einzubinden (wobei ich noch nirgends ein funktionierendes Beispiel gesehen habe),
oder die sqlite3.dll als Ressource in die EXE hinein zu kompilieren.
Ablauf dann wie folgt:
Programm startet
Check ob sqlite3.dll dort ist, wo es sein soll (neben der EXE oder ggfs. Unterordner)
Falls nein, extrahiere die DLL aus der Ressource, und speicher sie eben dort ab
Falls ja.....
Feuer frei

Ja, stimmt, das könnte man so machen.

Kennst Du zufällig ein vergleichbares Code-Beispiel für SQL-Anbindung,
wie ich es hier für DBF angehängt habe, in meinem Eingangs-Post ?

[af0815]

Gnerell kann man den AutoID nutzen und hängt seine Felder einfach dazu. Damit hat man einmal einen eindeutigen Index, der nicht von irgendwelchen Werten abhängt, wie das Datum (Tagespart zB). Man muss die Spalte ja nirgends dem Benutzer anzeigen, dafür ist sichergestellt das der Wert Tabelleneinzigartig ist. Und die komponeneten haben ein Primärschlüssel für die eindeutige zuordnung, der sich nicht mehr ändert, selbst wenn alle anderen Werte sich ändern. Ist auch ein Vorteil.