Unterstützt SQLite SCOPE_IDENTITY?

Question

Ich versuche, ein einfaches INSERT durchzuführen und die Identität zurückzugeben (automatisch inkrementierender Primärschlüssel). Ich habe versucht

cmd.CommandText = "INSERT INTO Prototype ( ParentID ) VALUES ( NULL ); SELECT SCOPE_IDENTITY();";

und ich erhalte die folgende Fehlermeldung

EnvironmentError: SQLite error
no such function: SCOPE\_IDENTITY

Unterstützt SQLite SCOPE_IDENTITY?
Wenn ja, wie verwende ich sie?
Wenn nicht, was sind meine (vorzugsweise "thread-safe") Alternativen?

Answer 1

Wenn Sie nicht die C-Schnittstelle für die Programmierung verwenden und den Prozess von einem SQL-Befehl aus durchführen wollen, versuchen Sie es: SELECT last_insert_rowid()

http://www.sqlite.org/lang_corefunc.html

Answer 2

Überprüfen Sie die FAQ . Die sqlite3_last_insert_rowid() Funktion wird es tun. Seien Sie jedoch vorsichtig mit Auslösern.

Answer 3

El last_insert_rowid() ergibt die Zeilen-ID der allerletzten Einfügung in eine beliebige Tabelle. Definitiv nicht thread-sicher, wie in anderen Antworten erwähnt.

Wenn Sie unbedingt brauchen um sicherzustellen, dass Sie die richtige Zeilen-ID zurückerhalten, unabhängig von Threads, Asynchronität usw. (z. B. wenn Sie beabsichtigen, die Zeilen-ID als Fremdschlüssel in einer anderen Tabelle zu verwenden), gibt es eine Möglichkeit:

1. eine Textspalte in die gewünschte Tabelle einfügen (diese wird eine GUID enthalten)
2. eine GUID manuell erzeugen (unter Verwendung der in Ihrer Sprache verfügbaren Bibliotheken) und im Speicher halten
3. Fügen Sie Ihre Daten in die Tabelle ein, zusammen mit der GUID, die Sie gerade erzeugt haben
4. die (vermeintliche) rowid abrufen über last_insert_rowid()
5. die Zeile (oder nur die GUID) aus Ihrer Tabelle mit dieser rowid abrufen
6. die GUID der abgerufenen Zeile mit der GUID vergleichen, die Sie noch im Speicher haben
   • wenn sie identisch sind, haben Sie die richtige rowid
   • Wenn sie unterschiedlich sind, müssen Sie die Tabelle nach einer Übereinstimmung mit der GUID abfragen, die Sie im Speicher für die richtige rowid haben.

Diese Lösung hat natürlich erhebliche Leistungseinbußen, und Sie müssen abwägen, ob die Risiken nicht übereinstimmender Daten die Leistungseinbußen überwiegen. In meinem Fall musste ich mich vor allem auf die Integrität meiner Daten verlassen können, so dass ich die Leistungseinbußen in Kauf nehmen konnte. (Wie groß die Einbußen waren, kann ich nicht sagen.)

Sie könnten den Drang verspüren, den 4. und 5. Schritt zu überspringen und die rowid mithilfe Ihrer GUID zu ermitteln; Sie könnten auch den Drang verspüren, die GUID einfach als Primärbezeichner und Fremdschlüssel zu verwenden. Nach all diesen würde den Code vereinfachen und weniger Spalten in Ihrer Tabelle bedeuten... WIDERSTEHEN SIE DIESEM DRANG. Ganzzahlen als primäre Bezeichner sind leicht indizierbar, was sie in WHERE-Klauseln und JOINS schneller/effizienter macht; eine GUID oder ein String lässt sich nicht so gut indizieren wie eine Ganzzahl.