ID nicht gefunden nach last_insert_rowid()

[himitsu]

Zitat von EdAdvokat:

Künftig greife ich natürlich darauf zurück, SQL-Statements auszuprobieren und erst dann einzusetzen. Habe ich da was falsch verstanden?

Nee.

Aber um ganz sicher zu gehn, baust du dir einfach eine Form mit Memo, DB-Grid und je einem Sendeknopf für Execute/Open auf, mit den Komponenten, die du verwendest. (oder es gibt eine Test-/Demo-App des Komponentenherstellers)
Da kannst du dann mit einer "vergleichbaren" Umgebung testen, wie in deinem Programm vorkommt
und bemerkst auch schon beim Testen Sonderprobleme bezüglich deiner Umgebung.

[EdAdvokat]

dazu habe ich den DBBrowser für SQL installiert und mit SQLite-DB-Tabellen experimentiert gem. Tutorials SQL. Damit habe ich auch die hier verwendeten SQL-Statements nachvollzogen, leider erst nach Finden der Lösung. Nichts destotrotz kann man ja weiter experimentieren und üben.

[nahpets]

Der DBBrowser verhält sich wie der DBBrowser.

Ein selbst mit Delphi geschriebenes Programm, verhält sich wie alle selbst mit Delphi geschriebenen Programme.

Der DBBrowser muss sich weder so wie ein Programm, dass Zeos nutzt verhalten, noch wie ein Programm des DBExpress nutzt.

Du wirst sicherlich eine große Übereinstimmung erhalten, aber nicht zwingend eine unbegrenzte Portierbarkeit.

In einem selbst geschriebenen Programm kannst Du genau sehen, wie sich ein selbst geschriebenes Programm in einer bestimmten Situation verhalten wird.

Mit dem DBBrowser erfährst Du nur, dass es mit dem DBBrowser funktioniert und kannst mutmaßen, dass es höchstwahrscheinlich mit 'nem Eigenbau auch so funktionieren wird.

Da Du aber gerade gemerkt hast, dass Du mit Zeos und DBExpress nicht zwingend ein gleiches Verhalten erwarten kannst, ist himitsus Vorschlag, was eigenes zu bauen, garnicht mal so verkehrt.

Und da es Dir ja in erster Linie ums lernen geht, wäre ein eigener DBBowser ja sicherlich nicht unbedingt das ungeeignetste Projekt.

Oder anders: Damit kannst Du genau die Unterschiede herausarbeiten und erfahren, wie Du sinnvollerweise vorgehst, um eben von den Unterschieden der Zugriffkomponenten wegzukommen.

[TRomano]

Die absolute Sicherheit gibt die Abfrage "SELECT MAX(ID) FROM ..." aber nun mal gar nicht in einer Multi-User-Umgebung mit hochfrequenten Eingaben.
Wer sagt denn, dass er seine ID des INSERT's bekommt und nicht die letzte eingefügte (und damit maximale) ID eines anderen Users? Da es in diesem Beispiel ja auch nicht über eine Transaktion geht funktioniert es so nicht zu 100%.
Genau dafür haben DB-Systeme wie Firebird die RETURNING_VALUE im INSERT-Statement.

[jobo]

Da kann ich nur voll zustimmen.
Allerdings sind wir in diesem Thread bei SQLite und das ist keine klassische Mehrbenutzerumgebung.
Folglich müsste hier die LastInsertRowID ausreichen und funktionieren.
Ich hätte nichts dagegen wenn SQLite RETURNING unterstützt, einfach aus Komforgründen.

[himitsu]

Alternativ kann man die ID eben auch selber füllen, vor abschicken des Posts die Sequenz abfragen, also im AfterInsert oder spätestens BeforePost(wenn NULL) holen und eintragen, so hat man da schon die richtige ID.

[jobo]

Zitat von himitsu:

Alternativ kann man die ID eben auch selber füllen, vor abschicken des Posts die Sequenz abfragen, also im AfterInsert oder spätestens BeforePost(wenn NULL) holen und eintragen, so hat man da schon die richtige ID.

Das ist aber in SQLite auch nicht konform zu echten RDBMS oder? Es gibt nur autoincrement, die SQLite selber verwaltet und das ist was anderes, als Sequenzen zu definieren und selbst zu verwalten/nutzen.

[Aviator]

Zitat von nahpets:

Da Du aber gerade gemerkt hast, dass Du mit Zeos und DBExpress nicht zwingend ein gleiches Verhalten erwarten kannst, ist himitsus Vorschlag, was eigenes zu bauen, garnicht mal so verkehrt.

Und da es Dir ja in erster Linie ums lernen geht, wäre ein eigener DBBowser ja sicherlich nicht unbedingt das ungeeignetste Projekt.

Oder anders: Damit kannst Du genau die Unterschiede herausarbeiten und erfahren, wie Du sinnvollerweise vorgehst, um eben von den Unterschieden der Zugriffkomponenten wegzukommen.

Wenn er komplett unabhängig von Komponenten sein will dann muss der über die DLL von SQLite arbeiten. Und das ist sehr aufwendig. Ich schreibe aktuell ein Programm das einem DBBrowser oder HeidiSQL oder auch dem Microsoft SQL Management Studio ähnlich/gleich kommt.

Der Aufwand für so ein Programm ist nicht zu unterschätzen. Ich würde mal behaupten, dass so ein Programm zum Lernen auch nicht zielführend ist da viel zu aufwendig.

[EdAdvokat]

jobo, Du schreibst

Zitat:

Allerdings sind wir in diesem Thread bei SQLite und das ist keine klassische Mehrbenutzerumgebung.
Folglich müsste hier die LastInsertRowID ausreichen und funktionieren.

LAST_INSERT_ROWID () funktionierte jedoch nicht. Lediglich mit dem SQL-Statement qMain.SQL.Text := 'SELECT ID FROM KONTAKTE ORDER BY ID DESC LIMIT 1'; kam ich ohne Fehlermeldung weiter. Mit den Zeos-Komp. klappte es auf Anhieb mit LAST_INSERT_ROWID (). Leider gibt es bei dbExpress nicht die Einstellmöglichkeiten der Zeos-Komp.

[nahpets]

Zitat von Aviator:

Zitat von nahpets:

Da Du aber gerade gemerkt hast, dass Du mit Zeos und DBExpress nicht zwingend ein gleiches Verhalten erwarten kannst, ist himitsus Vorschlag, was eigenes zu bauen, garnicht mal so verkehrt.

Und da es Dir ja in erster Linie ums lernen geht, wäre ein eigener DBBowser ja sicherlich nicht unbedingt das ungeeignetste Projekt.

Oder anders: Damit kannst Du genau die Unterschiede herausarbeiten und erfahren, wie Du sinnvollerweise vorgehst, um eben von den Unterschieden der Zugriffkomponenten wegzukommen.

Wenn er komplett unabhängig von Komponenten sein will dann muss der über die DLL von SQLite arbeiten. Und das ist sehr aufwendig. Ich schreibe aktuell ein Programm das einem DBBrowser oder HeidiSQL oder auch dem Microsoft SQL Management Studio ähnlich/gleich kommt.

Der Aufwand für so ein Programm ist nicht zu unterschätzen. Ich würde mal behaupten, dass so ein Programm zum Lernen auch nicht zielführend ist da viel zu aufwendig.

Naja, so meinte ich das nicht.

Hatte eher an ein TMemo, ein TDBGrid, 'ne TDataSource, 'nen TDBNavigator gedacht.

Für die Datenbankverbindung wird einmal Zeos genutzt und einmal DBExpress. (Und wer will nimmt auch noch die ADO-Komponenten, die sich auch wieder anders verhalten.)

Durch ändern der Querykomponente des DataSet von TDataSource kann man dann zwischen den unterschiedlichen Datenbankkomponeten hin- und herschalten.

Mir ging es eher darum ein Programm zu schreiben, das die vorhandenen Datenbankkomponenten nutzt und nicht ein Programm, das vollständig ohne die zu Delphi gehörenden Datenbankkomponenten auskommt.

Dass man sowas "nicht mal eben" schreiben kann, ist vollkommen klar.