ID nicht gefunden nach last_insert_rowid()

[EdAdvokat]

Ich habe eine kleine Adressverwaltung einmal mit den Zeos-Komponenten und das gleiche mit den dbExpress-Komp. geschrieben (natürlich unterscheiden sich beide hinsichtlich des Zugriffs auf die Datenbank).
Beide Programme funktionieren soweit exakt.
Nach Aufruf des Abschnitts:

Delphi-Quellcode:

qMain.SQL.Text:='SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE';
      qMain.Open;
      currentID:=qMain.FieldByName('ID').AsString;

läuft das Programm mit den Zeos-Komp. exakt durch und gibt auch die richtige ID aus.
Jedoch mit dbExpress-Komp wirft er an dieser Stelle eine Exception: qmain: Das Feld 'ID' wurde nicht gefunden.
Dies tritt jeweils bei der Eingabe eines neuen Datensatzes auf. In beiden Varianten wird jedoch der neue Datensatz gespeichert und erscheint nach Neustart des Programms exakt mit der entspr. fortlaufenden ID.
Muss man also bei Verwendung von dbExpress-Komp. anders verfahren? Ich habe einfach kühn die störende Zeile auskommentiert und er meckert nicht mehr. Ist das jedoch richtig?
Ich bin eher ein Anfänger in Bezug auf Datenbanken.
Den Fehler mit dem Debugger einzugrenzen gelang mir bislang nicht, denn an der entsprechenden Stelle gibt er mir auch nur die Fehlermeldung aus, die ich ohne Debugger im Programm lesen kann.
Kann ich mit dem Weglassen der Zeile im Programm mit dbExpreess-Komp. leben oder was sollte ich tun?
Hier die ganze Procedure uebernehmen:

Delphi-Quellcode:

procedure TMainFRM.btnuebernehmenClick(Sender: TObject);
var
  currentID: string;
begin
  qMain.SQL.Clear;
  qMain.Params.Clear;
  if flag then
  begin
    currentID:=lv.Selected.Caption;
    qMain.SQL.Text:='UPDATE KONTAKTE SET NAME= :NAM, VORNAME= :VNA, GEB= :GEB, STRASSE= :STR, Nr= :NR, PLZ= :PLZ, ORT= :ORT, TEL= :TEL, EMAIL= :EMA, BEMERKUNG= :BEM WHERE ID=:CID';
    qMain.ParamByName('CID').AsString:=currentID;
    qMain.ParamByName('NAM').AsString:=edtName.Text;
    qMain.ParamByName('VNA').AsString:=edtVorname.Text;
    qMain.ParamByName('GEB').AsString:=edtGeb.Text;
    qMain.ParamByName('STR').AsString:=edtStrasse.Text;
    qMain.ParamByName('Nr').AsString:=edtNr.Text;
    qMain.ParamByName('PLZ').AsString:=edtPLZ.Text;
    qMain.ParamByName('ORT').AsString:=edtOrt.Text;
    qMain.ParamByName('TEL').AsString:=edtTel.Text;
    qMain.ParamByName('EMA').AsString:=edtemail.text;
    qMain.ParamByName('BEM').AsString:=edtBemerkung.Text;
    qMain.ExecSQL;
    lv.Items.Clear;
    refreshItems(currentID,edtName.Text,edtVorname.Text,edtGeb.Text,edtStrasse.Text,edtNr.Text,edtPLZ.Text,edtOrt.Text,edtTel.Text,edtemail.Text,edtBemerkung.Text);
  end
  else
  begin
      qMain.SQL.Text:='INSERT INTO KONTAKTE(NAME,VORNAME,GEB,STRASSE,NR,PLZ,ORT,TEL,EMAIL,BEMERKUNG)'+'values(:NAM,:VNA,:GEB,:STR,:NR,:PLZ,:ORT,:TEL,:EMA,:BEM)';
      qMain.ParamByName('NAM').AsString:=edtName.Text;
      qMain.ParamByName('VNA').AsString:=edtVorname.Text;
      qMain.ParamByName('GEB').AsString:=edtGeb.Text;
      qMain.ParamByName('STR').AsString:=edtStrasse.Text;
      qMain.ParamByName('Nr').AsString:=edtNr.Text;
      qMain.ParamByName('PLZ').AsString:=edtPLZ.Text;
      qMain.ParamByName('ORT').AsString:=edtOrt.Text;
      qMain.ParamByName('TEL').AsString:=edtTel.Text;
      qMain.ParamByName('EMA').AsString:=edtemail.text;
      qMain.ParamByName('BEM').AsString:=edtBemerkung.Text;
      qMain.ExecSQL;
      qMain.SQL.Clear;
      qMain.Params.Clear;
      qMain.SQL.Text:='SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE';
      qMain.Open;
      currentID:=qMain.FieldByName('ID').AsString;
      qMain.Close;
      refreshItems(currentID,edtName.text,edtVorname.Text,edtGeb.Text,edtStrasse.Text,edtNr.Text,edtPLZ.Text,edtOrt.Text,edtTel.Text,edtemail.Text,edtBemerkung.Text);
  end;
    flag :=False;
    btnuebernehmen.Enabled:=False;
    btnabbrechen.Enabled:=False;
    lv.SetFocus;
end;

[Ghostwalker]

Ich kenn zwar jetzt die dbExpress nicht genau, aber evtl. mal guggen ob es sowas wie ein flush gibt.

Evtl. speichert dbExpress das irgendwo zwischen (Cache,Transaktion), so das das ganze noch nicht wirklich in
der DB steht (direkt nach Execute).

[jobo]

Keine Ahnung, hab das noch nie benutzt.
Die Funktion liefert diesen Rückgabewert offenbar ohne dass eine Tabelle dafür benötigt wird.

Also versuch mal die Tabelle im SQL wegzulassen (und das from)
Und nimm alternativ eine Werteabfrage ohne Feldname, nur per fields[0] oder lass Dir per GUI Kompos einfach mal ausgeben, was das SQL liefert.
Datasource und Grid an die Query klemmen und mal schauen, was wirklich zurückkommt.

[himitsu]

Wie ist die Tabelle definiert?

Hat sie überhaupt eine RowID?
Stichwort: WITHOUT ROWID
https://www.sqlite.org/c3ref/last_insert_rowid.html

Oder meinst du vielleicht last_insert_id?
Aber das hat SQLite nicht, also für die Spalte als PRIMARY KEY.

Echt schade, dass RETURNS nicht zum SQL-Standard gehört.
https://www.postgresql.org/docs/9.1/...efunction.html

Vielleicht mal als gemeinsames Script versuchen:

Delphi-Quellcode:

qMain.SQL.Text:='INSERT INTO KONTAKTE(NAME,VORNAME,GEB,STRASSE,NR,PLZ,ORT,TEL,EMAIL,BEMERKUNG)'+'values(:NAM,:VNA,:GEB,:STR,:NR,:PLZ,:ORT,:TEL,:EMA,:BEM);'#10;
               +'SELECT LAST_INSERT_ROWID() AS ID;';
qMain.ParamByName('NAM').AsString:=edtName.Text;
qMain.ParamByName('VNA').AsString:=edtVorname.Text;
qMain.ParamByName('GEB').AsString:=edtGeb.Text;
qMain.ParamByName('STR').AsString:=edtStrasse.Text;
qMain.ParamByName('Nr').AsString:=edtNr.Text;
qMain.ParamByName('PLZ').AsString:=edtPLZ.Text;
qMain.ParamByName('ORT').AsString:=edtOrt.Text;
qMain.ParamByName('TEL').AsString:=edtTel.Text;
qMain.ParamByName('EMA').AsString:=edtemail.text;
qMain.ParamByName('BEM').AsString:=edtBemerkung.Text;
qMain.Open;
currentID:=qMain.FieldByName('ID').AsString;
qMain.Close;
refreshItems(currentID,edtName.text,edtVorname.Text,edtGeb.Text,edtStrasse.Text,edtNr.Text,edtPLZ.Text,edtOrt.Text,edtTel.Text,edtemail.Text,edtBemerkung.Text);

PS: SQLite kennt ein

Delphi-Quellcode:

INSERT OR UPDATE

oder

Delphi-Quellcode:

INSERT OR REPLACE

, wie sie es nennen,
also bezüglich der beiden

Delphi-Quellcode:

UPDATE

und

Delphi-Quellcode:

INSERT INTO

.
https://www.sqlite.org/lang_insert.html

[EdAdvokat]

Die sqlite3-Tabelle hat foltende Struktur:
CREATE TABLE "Kontakte" ("ID" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL , "Name" VARCHAR(50), "Vorname" VARCHAR(50), "Geb" VARCHAR(12), "Strasse" VARCHAR(70), "Nr" VARCHAR(10), "PLZ" VARCHAR(10),
"Ort" VARCHAR(70), "Tel" VARCHAR(15), "email" VARCHAR(30), "Bemerkung" VARCHAR(80))

Ob sie damit wirklich eine RowID hat kann ich nicht sagen, doch ich gehe davon aus.(woran kann ich das erkennen?)
Zunächst habe ich das Programm mit dbExpress-Komp. geschrieben und an der bewußten Stelle die Exception erhalten. Dann dachte ich das ganze Programm so wie es ist einfach mit den Zeos-Komp. einzurichten und siehe da das hat geklappt.
Er geht ohne wenn und aber über die Hürde hinweg und gibt sofort die entsprechende ID in der ListView aus und alles ist paletti. Mit dbExpress hängt er an der Zeile:

Delphi-Quellcode:

currentID:=qMain.FieldByName('ID').AsString;

Er gibt keine ID aus, jedoch nach Neustart des Programms ist der neue Datensatz mit der entsprechenden nächstfolgenden ID gespeichert, als wäre nichts gewesen. Ich will ja nicht aus der Sache eine Haupt- und Staatsaktion machen, doch etwas komisch kommt es mir doch vor, zumal beide Programme bis auf den DB-Zugang gleich sind.
Jetzt habe ich die Zeile in dem dbExpress-Prog. einfach auskommentiert und alles läuft so ganz ok.
Nur eines ist bei beiden Varianten noch blöd: nach einem "bearbeiten" also verändern und UPDATE... ist dann stets nur der veränderte Datensatz im Listview zu sehen. Eigentlich wollte ich alle Datensätze einschließlich den veränderten sehen.
Da bin ich auch noch nicht weiter gekommen.

[nahpets]

Wenn man in 'nem Programm eine Datenmenge hat und z. B. in 'nem Grid anzeigt, so bekommt man dort per Insert, Update ... gemachte Änderungen nicht mit.

Auch über Trigger, Autoincrement ... vergebene Werte bekommt man nicht mit.

Man muss zuerst die Daten neu einlesen.

Da reicht ein Refresh der Datenmenge aus, ein Neustart des Programmes ist da eher suboptimal.

Zeos scheint aber etwas anders zu arbeiten, als andere Datenbankkomponenten.

Es kann sein, das Zeos das im Hintergrund irgendwie (teilweise?) erledigt bekommt.

[EdAdvokat]

Danke zunächst für die Unterstützung.
himitsu, zu deinem Vorschlag, habe es mit dem Code versucht:

Delphi-Quellcode:

qMain.SQL.Text:='INSERT INTO KONTAKTE(NAME,VORNAME,GEB,STRASSE,NR,PLZ,ORT,TEL,EMAIL,BEMERKUNG)'+'values(:NAM,:VNA,:GEB,:STR,:NR,:PLZ,:ORT,:TEL,:EMA,:BEM);'#10;
               +'SELECT LAST_INSERT_ROWID() AS ID;';

er bringt an dieser Stelle die Exception: Operator ist auf diesen Operantentyp nicht anwendbar.
Das geht vermutlich so nicht.
Zum "Problem" Anzeige veränderter Datensätze: Im "Zeos-Programm" gibt er einen neu erstellen Datensatz sofort im Listview sichtbar aus, neben den bereits gespeicherten DS. Lediglich beim Verändern eines DS (update) zeigt er den veränderten DS gesondert nur allein.
Wie in #1 zu erkennen habe ich doch ein refresh sowohl nach UPDATE als auch nach INSERT geschrieben.

[nahpets]

Aus dem Quelltext kann ich nicht erkenne, was in refreshItems passiert.

Dashier sind wohl eher zwei Statements:

Delphi-Quellcode:

qMain.SQL.Text:='INSERT INTO KONTAKTE(NAME,VORNAME,GEB,STRASSE,NR,PLZ,ORT,TEL,EMAIL,BEMERKUNG)'
+'values(:NAM,:VNA,:GEB,:STR,:NR,:PLZ,:ORT,:TEL,:EMA,:BEM)';
qMain.ExecSQL;
qMain.SQL.Text:='SELECT LAST_INSERT_ROWID() AS ID'; 
qMain.Open;
currentID:=qMain.FieldByName('ID').AsString;
qMain.Close;

[himitsu]

Entweder die SQL-Komponente versteht es oder es gibt eventuell eine zusätzliche Komponente, welche SQL-Scripte ausführen kann, also mehrere SQL-Statements zusammen.
Getrennt hat er es ja schon, aber eventuell muß last_insert_rowid in der selben Transaktion ausgeführt werden?


Wenn man nicht manuell via SQL-Statement dieses erledigt, sondern über Insert/Append, Edit und Delete von TDataSet, dann bieten viele DB-Komponenten auch ein UpdateRecord und sogar ein AutoUpdate des veränderten Records im DataSet an, wo dann auch die Änderungen von Triggern inbegriffen sind.
Die versuchen dann z.B. ID-Spalte der Tabelle zu erkennen (oder man nennt sie der Komponente), machen dann nach dem TDataSet.Post ein SELECT mit dieser ID (nehmen z.B. das SELECT-Statement und hängen ein WHERE mit dieser ID an) und aktualisieren ihre Daten.

[EdAdvokat]

Zitat:

napeths schrieb: Aus dem Quelltext kann ich nicht erkenne, was in refreshItems passiert.

Dashier sind wohl eher zwei Statements:

Hier in dem #1 am Anfang ist doch ein anderer Quelltext der procedure uebernehmen. Dort habe ich doch sowohl nach UPDATE als auch nach INSERT ein refresh eingefügt. War das nicht ausreichend, um die DS nach der Änderung (UPDATE) gemeinsam mit den bestehenden DS anzuzeigen?

[nahpets]

Bitte Quelltext von refreshItems.

Was genau passiert da?

[EdAdvokat]

Hier die Procedure RefeshItmems:

Delphi-Quellcode:

procedure TMainFRM.refreshItems(ID, Name, Vorname, Geb, Strasse, Nr, PLZ, Ort,
  Tel, email, Bemerkung: string);
var
  item: TListItem;
begin
  item:=lv.Items.Add;
  item.Caption:= ID;
  item.SubItems.Add(Name);
  item.SubItems.Add(Vorname);
  item.SubItems.Add(Geb);
  item.SubItems.Add(Strasse);
  item.SubItems.Add(Nr);
  item.SubItems.Add(PLZ);
  item.SubItems.Add(Ort);
  item.SubItems.Add(Tel);
  item.SubItems.Add(email);
  item.SubItems.Add(Bemerkung);
end;

die rufe ich dann nach UPDATE und INSERT auf.
ist das nicht ausreichend?

[nahpets]

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE';
qMain.Open;
if qMain.RecordCount > 0 then begin
  currentID := qMain.FieldByName('ID').AsString;
end else begin
  MessageDlg('LAST_INSERT_ROWID() liefert kein Ergebnis.',mtError,[mbok],0);
end;
qMain.Close;

Wie ist bei den ZEOS-Komponenten AutoCommit eingestellt?
Ebenso TransactIsolationLevel?

Eventuell gibt es da Abhängigkeiten, die es ZEOS ermöglichen, die Abfrage auf LAST_INSERT_ROWID() auszuführen, während bei anderen Datenbankschnittstellen hier kein Ergebnis geliefert wird.

[EdAdvokat]

Hallo Stefan, das sind ja die fast unergründlichen Tiefen der Komponenten:
Bei den Zeos-Komp. ist AutoCommit:= true;
und TransactlatsolatronLavel:=tinone
was auch immer das bedeuten soll. Jedenfalls hast Du mich in die Spur gebracht und ich werde wohl morgen daraufhin die dbExpress-Komp.-Einstellungen prüfen.
Könnten noch andere Unterschiede maßgeblich sein? Es ist doch spannend, auf was man alles achten muss.

[nahpets]

Als erstes interessiert mich, was bei meinem Quelltext 2 Posts höher rauskommt.

Exception, weil Feld nicht gefunden (also der bekannte Fehler) oder wird der Fehlerdialog angezeigt?

Das AutoCommit := True müsste bedeuten, dass das qMain.ExecSQL in einer eigenen Transaktion ausgeführt wird. Das Lesen von LAST_INSERT_ROWID() erfolgt also nach einem Commit.

Wenn andere Komponenten nicht jeweils eine eigene Transaktion machen, könnte es sein, dass es für LAST_INSERT_ROWID() noch keinen Wert gibt, weil der (eventuell) erst nach Abschluss einer Transaktion zur Verfügung steht.
Da müsste man sich dann mal durch die Datenbankdokumentation durchwühlen.

TransactIsolationLevel gibt an, ob Daten anderer Transaktionen gelesen werden, ob nur die per Commit festgeschriebenen oder auch die, die noch nicht per Commit festgeschrieben wurden ...

[EdAdvokat]

Hallo Stephan, nach Einfügen deines Code kommt folgende Exception:

Zitat:

qMain: Das Feld 'ID' wurde nicht gefunden

Also die bekannte Meldung.
In den dbExpress-Komp. gibt es leider nicht die Einstellmöglichkeiten der Zeos-Komp.
Ich könnte auch das anze Prog. posten, denn es ist nicht groß und dient lediglich meiner Übung.

[EdAdvokat]

setze ich

Delphi-Quellcode:

if qMain.RecordCount > 0 then begin

auf

Delphi-Quellcode:

RecordCount = 0 oder -1

kommt Dein geschriebener Meldungstext.
Der RecordCount sollte doch stets >0 sein. Also irgendwas hindert das Programm das Feld 'ID' zu finden. Mit Debugger das Prog. geprüft und genau an der Stelle

Delphi-Quellcode:

currentID := qMain.FieldByName('ID').AsString;

kommt die Exception. Es ist ja nicht weltbewegend und sicher könnte man damit leben, doch ich bin in der Lernphase und da interessiert mich so eine Kleinigkeit doch etwas, genau wie das Problem der einzelnen Darstellung des letzten veränderten Datensatzes ohne die vorhierigen Datensätze darzustellen nach Aufruf der Bearbeiten-Procedure.

[himitsu]

Weil das schon mehrmals gesagt, aber immer wieder übersehn wurde:

Zitat:

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE';
qMain.Open;
if qMain.RecordCount > 0 then begin

Delphi-Quellcode:

SELECT LAST_INSERT_ROWID() AS ID

ist eine globale Funktion
und

Delphi-Quellcode:

SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE

würde den Wert mehrmals liefern, für jeden Datensatz in KONTAKTE. :angle:

[nahpets]

Warum gibt es denn dann bei Zeos keinen Fehler, ansonsten aber schon?

Es müsste doch bei 'SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE' n Ergebniszeilen kommen, die alle den gleichen Inhalt haben. Mit dem Zugriff auf die erste Zeile und die Spalte ID müsste man doch trotzdem das richtige Ergebns bekommen (auch wenn dieses Vorgehen dann nicht so wirklich korrekt und sinnvoll wäre.)

[EdAdvokat]

verstehe ich himitsu richtig, dass die globale Funktion an dieser Stelle entbehrlich wäre und gestrichten werden sollte?
Nochmals habe ich das ganze im Prog. mit den Zeos-Komp. geprüft und da ist wirklich alles paletti. Der neue erstellte Datensatz wird sofort mit entsprechender ID! dargestellt und gespeichert, so wie ich es mir auch mit dem dbExpress-Komp-Prg. vorgestellt habe.
Im dbExpress-Prg. (mit auskommentierter Zeile!) wird nach Aufruf von übernehmen zwar der Datensatz angezeigt, jedoch ohne ID!. Erst nach Neustart des Programms ist der Datensatz dann mit entsprechender ID aufgeführt.
Es entsteht der Eindruck, dass im Prog. keine ID verarbeitet wird, aber die DB dann die ID vergibt, die dann nach Neustart des Programms exakt aufgeführt wird?!

[nahpets]

himitsu meint (zu recht), dass das SQL abgeändert werden muss:

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT LAST_INSERT_ROWID()';
qMain.Open;
if qMain.RecordCount > 0 then begin

Die globale Funktion liefert die ID auch ohne Angabe einer Tabelle.

Das bei den dbExpress-Prg. genannte Verhalten ist eigentlich eher der Normalfall.

Nach einem Insert muss man den Datensatz lesen, um die dann aktuellen Werte zu erhalten. Das Programm kennt nur die Werte, die es selbst mit dem Insert in die Datenbank schreibt, es kennt aber nicht die Werte, die dann (auf welchem Weg auch immer) von der Datenbank vergeben werden.

Das Lesen geht auch ohne einen Programmneustart.
Man muss halt die Routine, mit der man die Daten beim Programmstart liest, erneut aufrufen oder eine andere Leseroutine implementieren.

[EdAdvokat]

ich habe nun nach den Hinweisen von Stephan den Code verändert:

Delphi-Quellcode:

qMain.Params.Clear;
      qMain.SQL.Text:='SELECT * FROM KONTAKTE';
      //qMain.SQL.Text := 'SELECT LAST_INSERT_ROWID() AS ID FROM KONTAKTE';
      qMain.Open;
      if qMain.RecordCount >0 then begin
      currentID := qMain.FieldByName('ID').AsString;
      end else begin
      MessageDlg('LAST_INSERT_ROWID() liefert kein Ergebnis.',mtError,[mbok],0);
      end;
      qMain.Close;

Nun wird der neue Datensatz mit einer ID=1 ausgewiesen darbestellt. Nach Neuaufruf des Programms jedoch mit der entsprechenden ID der DB. Nun ist jedoch diese Funktion LAST_INSERT_ROWID() AS ID FROM KONTAKTE raus.Kann das so bleiben oder ist das eher Stückwerk?
Ich möchte das Programm möglichst so schreiben, dass ich es als Muster zum Lernen verwende und da sollte möglichst alles stimmen.

[nahpets]

Du liest nun im SQL alle Datensätze der Tabelle Kontakte und bekommst am Anfang den ersten Datensatz und der hat die ID 1.

Das hat aber nichts mit dem zu tuen, was Du erreichen möchtest. Du möchtest doch die ID des zuletzt eingefügten Datensatzes. Also musst Du auch die letzte ID lesen und das geht mit:

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT LAST_INSERT_ROWID()';
qMain.Open;
if qMain.RecordCount > 0 then begin

[EdAdvokat]

Stephan, wenn ich das so einfüge, wie Du geschrieben hast kommt eine Exception:

Zitat:

[0x0005]:Operation wir nicht unterstützt

So kann man wohl den letzten INSERT-Datensatz nicht abfragen.

[nahpets]

Einen hätt' ich noch:

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT max(ID) as ID from KONTAKTE';
qMain.Open;
if qMain.RecordCount > 0 then begin
  currentID := qMain.Fields[0].AsString;

[himitsu]

Zitat:

Zitat von EdAdvokat (Beitrag 1371332)

verstehe ich himitsu richtig, dass die globale Funktion an dieser Stelle entbehrlich wäre und gestrichten werden sollte?

Jupp, diese Funktion liefert die letzte ID, vom letzten INSERT, egal auf welche Tabelle.

Wenn du unbedingt willst, dann kannst du auch gern alle deine Tabellen miteinander JOINen und Millionen Datensätze abrufen, aber es ändert nichts daran, dass diese Funktion global ist und nicht an einer Tabelle hängt.
Es kommt immer das selbe Ergebnis raus ... nur halt mehrfach.

SQL-Code:

SELECT last_insert_rowid() AS ID FROM KONTAKTE JOIN SONSTWAS ON TRUE JOIN NOCHWAS ON TRUE JOIN ...;

SELECT current_user() AS ID FROM KONTAKTE JOIN SONSTWAS ON TRUE JOIN NOCHWAS ON TRUE JOIN ...;

SELECT date('now') AS ID FROM KONTAKTE JOIN SONSTWAS ON TRUE JOIN NOCHWAS ON TRUE JOIN ...;

Zitat:

SQL-Code:

SELECT * FROM KONTAKTE

Fragt natürlich sinnlos alle Felder der Tabelle ab, obwohl nur das ID-Feld verwendet wird.

SQL-Code:

SELECT ID FROM KONTAKTE

Aber hier kommen natürlich alle IDs an, und das auch noch in beliebiger Reihenfolge.
Dass zufällig die ID des ersten Datensatzes die richtige ID ist, ist eher unwahrscheinlich.

SQL-Code:

SELECT ID FROM KONTAKTE ORDER BY ID DESC

So wäre als erster Datensatz schonmal das Richtige, aber es werden natürlich immernoch sinnlos alle anderen Datensätze mit runtergeladen.

SQL-Code:

SELECT ID FROM KONTAKTE ORDER BY ID DESC LIMIT 1 -- oder SELECT FIRST 1 ID FROM KONTAKTE ORDER BY ID DESC ???

und das schon genannte MAX wäre auch ein guter Weg

SQL-Code:

SELECT MAX(ID) FROM KONTAKTE

Natürlich funktioniert das alles nur, wenn die IDs aufsteigend sind und es keine Lücken gibt, welche automatisch gefüllt werden,
also nur, wenn die letzte ID auch immer die Größte ist.

[EdAdvokat]

Himitsu's Vorschlag hat es gebracht:

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT ID FROM KONTAKTE ORDER BY ID DESC LIMIT 1';

So wird nach dem Einfügen (INSERT) eines neuen Datensatzes dieser mit exakter ID richtig angezeigt und gespeichert.
Die Variante

Delphi-Quellcode:

qMain.SQL.Text := 'SELECT max(ID) as ID from KONTAKTE';

hat nicht geklappt.
Ich habe ein Verständnisproblem: Wir wollten doch die ID des letzten eingefügten DS bekommen. Warum führt da DESC zum Ziel, das doch absteigend sortiert? Was bewirkt LIMIT 1?
Habe zwischenzeitlich auf der SQLite3-Seite gestöbert: https://www.sqlite.org/c3ref/last_insert_rowid.html
Dort sind div. Funktionen aufgeführt die zumeist mit SQLITE3_... beginnen, doch deren Verwendung führt dazu dass Embar. meint, diese Funktionen nicht zu kennen. Wie ist das zu verstehen?

Entschuldigung: habe soeben meinen Denkfehler erkannt: ja wir wollen doch die ID des letzten Datensatzes also muss es rückwärts gehen, also DESC!. Liege ich da richtig? und Limit 1 damit wirklich nur die ID des letzten DS verarbeitet wird?!

[himitsu]

Eigentlich müsste MAX aber auch funktionieren.
https://www.sqlite.org/lang_aggfunc.html

Und ja, DEST ist absteigend, also steht der größte Wert oben und der erste Datensatz des Ergebnisses wird ja auch genommen.

[EdAdvokat]

habe Variante:

Delphi-Quellcode:

qMain.SQL.Text:='SELECT MAX(ID) FROM KONTAKTE';

erfolglos probiert. Wieder die bekannte Exception, dass er das Feld 'ID' nicht finden könne. Komisch. Sind die SQL Befehle auf der von mir benannten Seite auch in Delphi gültig?
Ich danke Euch für die Hilfe und Unterstützung. Nun werde ich noch das Problem mit der Anzeige aller DS nach Bearbeiten zu lösen versuchen.

[himitsu]

Zitat:

SQL-Code:

SELECT MAX(ID) FROM KONTAKTE

Ohh ja, da heißt das Feld natürlich 'MAX', also so wie die Funktion, aus der das Ergebnis kommt. :lol:

SQL-Code:

SELECT MAX(ID) AS ID FROM KONTAKTE

Darum gab es auch schon ein paar Vorschläge mit

SQL-Code:

SQL.Fields[0]

anstatt

SQL-Code:

SQL.FieldByName('ID')

.

[nahpets]

Ich schrieb nicht ganz umsonst:

Delphi-Quellcode:

SELECT MAX(ID) AS ID FROM KONTAKTE

Wenn Du dann

Delphi-Quellcode:

SELECT MAX(ID) FROM KONTAKTE

nimmst, ist das natürlich was anderes.

Bitte übernimm bei Vorschlägen den ganzen Quelltext und nicht nur irgendwelche Teilmengen. Das kann bei der Fehlersuche deutlich hilfreich sein.

Wenn man MAX(ID) in 'nem SQL hat, dann heißt das nicht zwingend, dass die Spalte im Ergebnis dann auch Max heißt. Bei SQLite und FireBird mag das so sein.
Andere Datenbanken liefern dann auch schonmal Expr_1 oder, je nach Anzahl der verwendeten Funktionen Expr_1 bis Expr_n.

Man sollte bei Funktionen immer ein AS Spaltenname machen, damit man weiß, wie die Spalte im Ergebnis heißen wird.

[nahpets]

Wenn's ums Lernen geht:

Bezüglich SQL: Einführung in die SQL Grundlagen

Auf der Seite wird auch beschrieben, was es mit dem AS auf sich hat: Daten abfragen

Viel mehr zum Thema: Grundlagen SQL

Bevor man sich da datenbankspezifisch auf die Besonderheiten der einzelnen System "stürzt", lieber erstmal allgemein informieren.

[EdAdvokat]

Hallo Stephan, in #27 habe ich bereits dein Lösungsvorschlag beschrieben und leider erfolglos geprüft und gepostet.

Delphi-Quellcode:

qMain.SQL.Text:='SELECT MAX(ID) AS ID FROM KONTAKTE';

erfolglos probiert. Ebenfalls die bekannte Exception. Ich bemühe mich durchaus exakt die Vorschläge aufzugreifen und zu prüfen.
Ich habe mir bezüglich SQL-Tutorials schon einiges angesehen und werde die Tipps natürlich auch aufgreifen.

[himitsu]

Einen Tipp hast du vergessen.

* SQL-Tools verwenden
* oder dir selber einen SQL-Betrachter basteln.
Also ein DBGrid, was das gesamte Ergebnis einer SQL-Abfrage anzeigt und am Besten auch den Typ der Felder erkenntlich macht.

[EdAdvokat]

Himitsu, doch durchaus habe ich mir einen DBBrowser installiert und mit einem SQL-Tutorial praktischBeispiele probiert. Natürlich bin ich noch nicht in alle Untiefen der SQL-Sprache eingedrungen.

Noch an Wort zu Stephans Kritik: Das von mir erwähnte Beispiel war ein Vorschlag von himitsu aus dem Post #26. Das leider nicht funktioniert hat. Ich habe nicht dein SQL-Select gemeint. Kommt sicher schon mal vor, bei den Häufungen an Versuchen.

[himitsu]

Zitat:

doch durchaus habe ich mir einen DBBrowser installiert

Aber da fällt dann auch auf, wie die Spalte bei

SQL-Code:

SELECT MAX(ID) FROM KONTAKTE

heißt. :angle:

[EdAdvokat]

ja die heißt MAX(ID) und nicht ID, wie sie heißen sollte. Noch eine kurze Erklärung von mir: Ich habe überhaupt nicht in die Richtung gedacht, da es mit ROWID und den Zeos-Komp. wunderbar geklappt hat, dass es an einem nicht exakten SQL-Statement liegen könnte und in diese Richtung weiter gedacht werden muss. Jetzt nach Eurer Erklärung sind mir die Augen geöffnet worden - so ein wenig zumindest. Das was ich zur Funktion rowID... gefunden habe, war für mich nicht so erhellend, obwohl ich doch einiges leider überwiegend engl. auf der SQLite-Seite gelesen habe. Ich war der Auffassung, dass es an etwas anderem liegen muss, als an dem bewußten SQL-Statement mit der Funktion RowID...
Das Darstellungsproblem nach Bearbeiten habe ich zwischenzeitlich auch gelöst. Jetzt läuft alles vermutlich exakt.
Ich suche noch immer vergeblich nach Quelltexten zu einfachen Datenbankanwendungen, die ich als Beispiel zum lernen verwenden könnte. Ähnlich wie dieses einfache Adressprogramm zu SQLite. Gibt es da einen Tipp, wo ich suchen könnte ggf. auch zu anderen Datenbankanwendungen.
Danke nochmals für die Unterstützung.

[haentschman]

Moin...:P
Was ich nicht verstehe...warum du einmal mit Zeos und das andere Mal mit DBExpress arbeitest? Du bist noch in der Lernphase...da reicht eigentlich Zeos Dicke aus. 8-)

[nahpets]

Naja, die Methode ist doch ganz einfach:

Zuerst wird ein Statement außerhalb des Quelltextes, also mit 'ner Datenbankoberfläche, ausprobiert. Und erst dann, wenn es da fehlerfrei funktioniert, wird es ins Programm übernommen.

Und die Vergabe der Spaltennamen überlässt man weder der Datenbank noch der Datenbankoberfläche, sondern macht sie immer selbst.

Wird 'ne Spalte "einfach so" abgefragt, stimmt er im Abfrageergebnis mit dem in der Datenbanktabelle überein.

Sobald man eine Funktion, eine Case-Statement, 'nen Cast ... nutzt, gibt man den Namen mit as Spaltenname an. Dann weiß man, was man als Ergebnis bekommt.

[EdAdvokat]

Hallo Haentschmann, zur Erklärung: Ich wollte das Programm mit dbExpress-Komp. für mich als Übung und Muster schreiben und bin dann an der bewußten Stelle auf Schwierigkeiten gestoßen, die ich mir nicht erklären konnte. Als Mittel der Wahl dachte ich, versuche es doch mal mit den Zeos-Komp. mit denen ich bislang gute Erfahrungen gemacht habe und siehe da da es ging wunderbar. Doch ich will langsam meinen Horizont erweitern und auch mit den dbExpress-Komp. arbeiten. Das war einzig und allein der Grund und wie sich gezeigt hat kann man dabei auch noch was lernen, was mir bei den Zeos-Komp. entgangen wäre.
Zum post von Stephan:

Zitat:

Zuerst wird ein Statement außerhalb des Quelltextes, also mit 'ner Datenbankoberfläche, ausprobiert. Und erst dann, wenn es da fehlerfrei funktioniert, wird es ins Programm übernommen.

Und die Vergabe der Spaltennamen überlässt man weder der Datenbank noch der Datenbankoberfläche, sondern macht sie immer selbst.

Ich gebe bei der Erstellung der DB die Spaltennamen an und im Programm arbeite ich damit. Wenn eine Abfrage durchgeführt wird, gebe ich diese Spaltennamen an. Dass das Problem an dem nicht exakten SQL-Statement liegt habe ich wie zuvor erklärt dazumal nicht erkannt. Künftig greife ich natürlich darauf zurück, SQL-Statements auszuprobieren und erst dann einzusetzen. Habe ich da was falsch verstanden?