SQLite, Daten werden nicht in der DB gespeichert

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
Ununoctium
Beiträge: 3
Registriert: Mo 29. Dez 2008, 13:46

SQLite, Daten werden nicht in der DB gespeichert

Beitrag von Ununoctium »

Hallo Zusammen,
seit mehreren Tagen versuche ich nun schon Daten in einer SQLite DB zu ändern. Auch das durchforsten etlicher Foren und das ausprobieren mit etlichen Einstellungen brachte mich nicht weiter, deswegen wende ich mich jetzt an euch.
(Kurz zu meiner Person, ich habe währen eines Praxissemester schon mal mit Delphi7 gearbeitet, bin also kein blutiger Anfänger, aber sicherlich auch kein Profi.)

Aber hier mal die Details, folgendes habe ich:
  • Lazarus 0.9.26 mit FPC 2.2.2
  • Datamodul mit den Komponenten:
    TSQLite3Connection, TSQLTransaction, TSQLQuery
    TSQLTransaction ist mit TSQLite3Connection verbunden, TSQLQuery mit TSQLTransaction und TSQLite3Connection.
  • Form mit den Komponenten:
    TDatasource, TDBGrid
    TDatasource ist mit TSQLQuery verbunden und TDBGrid mit TDatasource
Soweit überhaupt nichts besonderes, und so wie es in etlichen Foren und Tutorien nachzulesen ist. Nach meinem Verständnis sollte jetzt alles soweit funktionieren. Das tut es aber leider nur zum Teil.

Das mache ich damit und was ist das Problem:
  • Bei dem Ereignis OnFormShow stelle ich die Verbindung zu DB her.
  • Nun lese ich einen Datensatz aus der DB ein, der wird im DBGrid angezeigt.
  • Nun ändere ich diesen Datensatz, das habe ich so gemacht:

    Code: Alles auswählen

    DM.SQLQuery1.Edit;
    DM.SQLQuery1.FieldByName('vok').AsString:='nicht das alte'; 
    DM.SQLQuery1.Post;
    oder auch mit diesem statt dem .Post

    Code: Alles auswählen

    DM.SQLQuery1.ApplyUpdates;
    oder auch so:

    Code: Alles auswählen

    DM.SQLQuery1.Close;
    DM.SQLQuery1.SQL.Clear;
    DM.SQLQuery1.SQL.Add('update fach set vok="nicht das alte" where id="1" '); 
    DM.SQLQuery1.ExecSQL;
    usw. das Ergebnis ist immer das selbe, die Änderung ist im DBGrid zu sehen, auch wenn der Datensatz mit einem select-Befehl oder mit einem Refresh neu eingelesen wird, ist die Änderung noch da. Schaue ich allerdings mit einem SQLite-Manageprogramm auf die DB ist die Änderung dort nicht angekommen!?
Warum ist die Änderung nun im DBGrid zu sehen und über die Laufzeit des Programmes auch verfügbar, aber doch nicht wirklich in der DB angekommen?

Und was mich jetzt noch ganz aus der Bahn wirft ist:
Ich habe das alles dann auch mal noch mit den Zeos-Komponenten gemacht. Damit funktioniert es ohne Probleme, die Änderungen werden auch wirklich übernommen. Leider soll das Programm später mal auf WIN CE laufen und das ist dann auch schon das Aus für die Zeos-Komponenten.

Hat vielleicht jemand eine Idee woran das liegen könnte, dass es mit den Komponenten von Lazarus nicht funktioniert, oder welche Einstellung ich ggf. noch übersehen habe?
Folgendes Punkte habe ich bereits „abgearbeitet“:
  • Transaction.Action mit caCommit usw.
  • Query.ReadOnly:=False
  • Query.UpdateMode mit upWhereKeyOnly usw.
  • Query.UsePrimaryAsKey:=True
  • Die Query Ereignisse BeforeInsert usw. habe ich überprüft ob diese wirklich statt finden.
  • Die Datensätze der DB besitzt natürlich einen PrimaryKey (AutoInt, Not Null).
  • Meines Wissens kennt SQLite keine User-Verwaltung, muss daher keinen User angeben!?
Schon mal vielen Dank!
Und für all diejenigen, die das hier vor dem 31.12. 23:59 lesen, einen guten Rutsch ins Jahr 2009!

Grüße
Mathias

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6766
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von af0815 »

Dumme Frage, zuerst Post UND DANN ApplyUpdates gemacht ?
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Poelser
Beiträge: 55
Registriert: Do 6. Nov 2008, 14:16
OS, Lazarus, FPC: Windows Vista (L 1.0.6 FPC 2.6.0)
CPU-Target: Intel 32 Bit/Arm

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von Poelser »

Ununoctium hat geschrieben:
  • Meines Wissens kennt SQLite keine User-Verwaltung, muss daher keinen User angeben!?
Dein Wissen ist da richtig!

CU, Eddi

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von mse »

Ununoctium hat geschrieben: Warum ist die Änderung nun im DBGrid zu sehen und über die Laufzeit des Programmes auch verfügbar, aber doch nicht wirklich in der DB angekommen?
Da fehlt vermutlich noch tsqltransaction.commit.

Martin

Ununoctium
Beiträge: 3
Registriert: Mo 29. Dez 2008, 13:46

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von Ununoctium »

Danke für die schnellen Antworten!
Ich habe eure Vorschläge gleich mal ausprobiert und inzwischen funktioniert es :D
mse hat geschrieben:Da fehlt vermutlich noch tsqltransaction.commit.
Hieran lag es!

Und so klappt es jetzt:

Code: Alles auswählen

DM.SQLQuery1.Edit;
DM.SQLQuery1.FieldByName('vok').AsString:='nicht das alte';
DM.SQLQuery1.ApplyUpdates;
DM.SQLTransaction1.Commit;
Was mich ein wenig irritiert, ist das ich meine von "SQLTransaction1.Commit;" in den Tutorien nichts gelesen zu haben, oder ich bin einfach nur blind gewesen. Sollte letzteres zutreffen, dann entschuldige ich mich für diesen Thread! Oder die haben halt wie die halbe Welt die Zeos-Komponenten verwendet!?

Noch mal vielen Dank an Martin, Eddi und af0815!!!

Grüße
Mathias

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von mse »

Ununoctium hat geschrieben: Was mich ein wenig irritiert, ist das ich meine von "SQLTransaction1.Commit;" in den Tutorien nichts gelesen zu haben,
Soviel ich weiss berücksichtigt FPC TSQLTransaction die Action property bei EndTransaction nicht - im Gegensatz zu MSEide+MSEgui welches eine weitere Alternative zu ZEOS und FPC Sqldb wäre. Allerdings wurde es bis jetzt nicht auf CE portiert. Bist du sicher, dass Lazarus/ZEOS nicht auf CE läuft?

Nachtrag: Die FPC Komponente TSqlite3Dataset ist eine weitere Alternative.

Ununoctium
Beiträge: 3
Registriert: Mo 29. Dez 2008, 13:46

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von Ununoctium »

mse hat geschrieben:Bist du sicher, dass Lazarus/ZEOS nicht auf CE läuft?
Ein klares Nein oder Ja zu dieser Frage habe ich nirgends gefunden. Nur dieses hier:
http://www.delphipraxis.net/topic145550,0.html" onclick="window.open(this.href);return false;

Ich habe das selbe festgestellt, beim kompilieren gibt es Fehlermeldungen, wie schwerwiegend diese sind kann ich nicht beurteilen.

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von mse »

Ununoctium hat geschrieben: Ein klares Nein oder Ja zu dieser Frage habe ich nirgends gefunden.
Frag doch mal hier:
http://zeos.firmos.at/portal.php

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von Christian »

Mit ZeOS geht das mit den Defaulteinstellungen alles auch so da gibts son AutoApplyupdates o.ä.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: SQLite, Daten werden nicht in der DB gespeichert

Beitrag von mse »

Christian hat geschrieben:Mit ZeOS geht das mit den Defaulteinstellungen alles auch so da gibts son AutoApplyupdates o.ä.
Yup, mit MSEgui ebenfalls, dort heisst es tmsesqlquery.controller.options dso_autoapply, dso_autocommit, dso_autocommitretaining, dso_refreshafterapply.

Antworten