ID nicht gefunden nach last_insert_rowid()

[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.

[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.

[jobo]

Zitat von 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.

Ja, hab ich verstanden, dass es nicht funktioniert.

Also meine Sicht nochmal (ich hab keine Möglichkeit, es zu testen):
Die Funktion last_insert_rowid() ist der "SQLite" Weg, diesen Wert zu bekommen. Dass es bei DB Express nicht funktioniert, ist vielleicht so, wir suchen nach workarounds.
Aber zu Klarstellung:
Die Funktion in der Form "select last_insert_rowid() from <tabelle>" ergibt für mich keinen Sinn, weil sie unabhängig von der Tabelle arbeitet und etwas/einen Wert zurückliefert, den es nicht pro Zeile gibt. ( Schön das sie mit zeos so funktioniert. )
Sinn ergäbe m.E. eine Abfrage "select last_insert_rowid();" Ende. Die Funktion liefert einen konstanten Wert, auch wenn in der Tabelle Millionen Datensätze stehen.
siehe z.B. > http://www.w3resource.com/sqlite/cor...sert_rowid.php

Wenn nun hier vorgeschlagen wird, mit Sequenzen zu arbeiten, dann ist das bezogen auf SQLite schwierig. M.E. müsste es erst selbst implementiert / nachgebaut werden.
SQLite bietet zwar "Sequenzen" im weitesten Sinne, aber eben nur eine einzige feste Implementierung in Form von Autoincrement.

Die angesprochene "Returning Clause" dient in "großen Datenbanken", den Wert einer (oder mehr) beliebigen, eingefügten Spalte aus dem Insert zurückzuliefern. Das kann ein Wert aus einem Autoincrement sein, aus einer selbst angelegten Sequenz oder anderes. Hilft Dir in SQLite nicht, gibt's nicht. Mein Zitat gilt lediglich der Tatsache, dass ein light weight, single User System wie SQLite per Definition mit dem last_insert_rowid() Konstrukt auskommen kann und kein RETURNING unterstützen muss. Das gilt zumindest solange, wie es tatsächlich als Single User System eingesetzt wird.

Ich kann mir eigentlich nicht vorstellen, dass die DBExpress Komponenten das nicht können, aber Du kannst folgendes ausprobieren:
lege eine Hilfstabelle mit einem Datensatz an. Eine Spalte reicht, Typ egal.Vielleicht klappt damit dann der DBExpress Aufruf:
"Select last_insert_rowid() from Hilfstabelle_mit_einem_Datensatz"
(Natürlich nach mindestens einem Insert, und zwar egal in welche andere Tabelle)

[nahpets]

Zitat von jobo:

Ich kann mir eigentlich nicht vorstellen, dass die DBExpress Komponenten das nicht können, aber Du kannst folgendes ausprobieren:
lege eine Hilfstabelle mit einem Datensatz an. Eine Spalte reicht, Typ egal.Vielleicht klappt damit dann der DBExpress Aufruf:
"Select last_insert_rowid() from Hilfstabelle_mit_einem_Datensatz"
(Natürlich nach mindestens einem Insert, und zwar egal in welche andere Tabelle)

Die Idee finde ich gut, ist letztlich nix anderes als bei Oracle.

select LAST_INSERT_ROWID() from dual

Die Tabelle könnte dann ungefähr so aussehen:

SQL-Code:

create table dual (dummy Char(1));
insert into dual (dummy) values ('X');

Könnte man bei FireBird und Co. eigentlich auch machen, dann muss man da nicht immer nach einer passenden Alternative suchen und kann derartige Statements datenbankunabhängig nutzen.

[jobo]

Zitat von nahpets:

Die Tabelle könnte dann ungefähr so aussehen:

Ja, man sollte aber sicherheitshalber- wenn es über einen Test hinaus geht und man das ernsthaft einsetzen will- noch ein paar brauchbare Constraints draufpacken, sodass weder versehentlich
- ein Datensatz eingefügt
- noch gelöscht werden kann

Selbstverständlich nachdem eben genau ein Datensatz drin ist.

[himitsu]

Zitat von nahpets:

select LAST_INSERT_ROWID() from dual

Wieso das FROM?

Lies nochmal die vielen vorhergegehen Posts.



SELECT CAST(last_insert_rowid() AS INTEGER) AS ID
Da es ja in der DB keine Probleme gibt, aber bei unterschiedlichen Zugriffskomponenten,
würde ich es nochmal mit einem CAST probieren, falls es einen "komischen" Typ zurück gibt, denn dbExpress einfach nur nicht mag.

[nahpets]

@himitsu

from weil dann egal welche Datenbank.

Bei SQLite geht auch ein select funktion Bei manchen anderen Datenbanken auch, bei Oracle nicht, bei FireBird auch nicht.

Oracle kennt die Tabelle dual.

Bei FireBird kann man dann RDB$Database nehmen, weil da immer ein Datensatz drin ist.

Meine Idee war halt, nach Jobos Anregung, analog zu Oracle einfach "überall" eine Tabelle dual anzulegen. Damit wären dann SQLs zwischen Datenbanken portierbar und müssten nicht, abhängig von der Datenbank, gegen die ein Programm läuft, angepasst werden.

Und da ich für gewöhnlich Software schreibe, bei der zur Entwicklungszeit die Zieldatenbank noch unbekannt ist, bzw. die Software datenbankunabhängig sein muss, halte ich das jetzt nicht unbedingt für eine so schlechte Idee.

[jobo]

Zitat von himitsu:

Zitat von nahpets:

select LAST_INSERT_ROWID() from dual

Wieso das FROM?

Lies nochmal ...

Ja, es ist ein großes Durcheinander mit vielen Vorschlägen.
Die "Erfindung" einer Eindatensatztabelle soll ja nur eine Krücke sein, um die DB Express Komponenten zu überlisten und zur klaglosen Arbeit zu bewegen.
Ja, so ist das bei Oracle üblich.
So machen es viele Oracle nach / analog (um kompatibler zu werden)
Ja, eine solche Tabelle gibt es bei Firebird bereits wie von nahpets geschrieben, hatte ich verdrängt.
Nein, ich bin mir nicht sicher, dass die DB-Express Kompos auf die Art überredet werden müssen, aber der Test dauert 1 Minute.
Ja, vielleicht ist es nur ein Typproblem, hab den Faden verloren, welche Fehlermeldungen gab es?