Auto-ID des eben eingefügten Datensatzes erhalten

[Daniel]

Mohoin,

furchtbar - ich, Delphi und Datenbanken. :roll:

Also: Ich versuche, aus einer Delphi-Anwendung heraus Daten in eine Datenbank zu schreiben. Mittels einer TSQLConnection verbinde ich mich auf den (lokalen) MySQL-Server und mittels einer TSQLQuery haue ich die Daten rein. Das geht auch ganz reizend:

Delphi-Quellcode:

with SQLQuery1 do
begin
  SQL.Text:= 'insert into static_docs (`title`, `docpath`, `key`, `namespace`, `type`, `prgLang`, `natLang`, `text` ) ' +
  'values(:title, :docpath, :key, :namespace, :type, :prgLang, :natLang, :text );';

  Params.ParamByName('title').AsString:= metaData.title;
  Params.ParamByName('docpath').AsString:= metaData.docpath;
  Params.ParamByName('key').AsString:= metaData.itmKey;
  Params.ParamByName('namespace').AsString:= metaData.itmNamespace;
  Params.ParamByName('type').AsInteger:= Integer( metaData.itmType );
  Params.ParamByName('prgLang').AsInteger:= Integer( metaData.prgLanguage );
  Params.ParamByName('natLang').AsInteger:= Integer( metaData.natLanguage );
  Params.ParamByName('text').LoadFromStream(memDest, ftBlob);

  ExecSQL;
end;

Jeder Datensatz dieser Tabelle bekommt von der Datenbank eine ID, die mittels Auto-Increment zugewiesen wird. Auch das geht - aber genau diese ID brauche ich in der weiteren Verarbeitung meiner Delphi-Anwendung. In der Hilfe zu TSQLQuery kommt das unschöne Wort "unidirektional" vor, was mir suggeriert, das der von mir gewählte Ansatz hierfür nicht geeignet ist.

Was könnt' ich denn machen, um an die Auto-ID des eben eingefügten Datensatzes zu kommen?
:cry:

[mkinzler]

Ich weiß nicht ob das mit MySQL klappt:

SQL-Code:

select ... into :id;

[alcaeus]

Moin,

wenn du folgendes Query ausfuehrst:

SQL-Code:

SHOW TABLE STATUS LIKE static_docs;

erhaelst du unter anderem die naechste autoinc-ID zurueck (Feld "Auto_increment"). Wenn du von dem Wert 1 abzaehlst, solltest du die naechste ID kriegen. Soweit ich weiss werden die autoinc-IDs immer fortlaufend vergeben; evtl. freigewordene IDs bleiben frei. Du solltest die Tabelle allerdings in einen Lock-State setzen, damit niemand reinpfuschen kann, und wenn du was anderes als MyISAM oder InnoDB als Tabellen-Typ verwendest, funktioniert diese Loesung auch nicht.

Greetz
alcaeus

[Hansa]

Weiß nicht, was jetzt genau SQLquery1 darstellt. Ist es ein DataSet, dann kriegt man zwar eine Datenmenge zurück, aber keinen Output-Parameter. Kleiner, aber feiner Unterschied. Syntax siehe hier :

http://www.w3schools.com/sql/sql_select.asp

Verwende eine stored Procedure, da gehts. D.h. allerdings für MySQL : ab V5.0 Alles ohne Gewähr !!

[Daniel]

Danke Euch.

Ich sehe schon, ich sollte mich mal ernsthaft mit dem Thema "Datenbanken" befassen. Die SQL-Seite ist nicht das Problem, die Ansteuerung von Delphi aus ist es, die mir Kopfzerbrechen bereitet.

[bttb930]

Moin,

wenn Du's nicht per INSERT INTO einbfügst, sondern per TADOTable oder TADOQuery, dann kannst Du an das Table bzw. die Query (SELECT * FROM MyTable) mit Add einen Datensatz anfügen. Danach setzt DFu alle Felder und machst dann Post. Jetzt sind die Daten gespeichert. Anschließend (nach dem Post) kannst Du auf die ID zugreifen - soweit ich weiß ist sie jetzt gesetzt.

Probier es sicherheitshalber aber noch aus.

[Delami]

Ich finde das mit den AutoID auch immer ein elendes Gefummel, und letztlich benutze ich dann das, was immer geht. Ich erzeuge einen neuen Datensatz der z.B. als Nachnamen '999999' enthält. Mit 'select * from meineTabelle where NachName='999999''. Jetzt habe ich die ID und kann NachName neu vergeben. Nicht elegant aber geht... :gruebel:

[Igotcha]

MySQL bietet dazu das Statement

Delphi-Quellcode:

ZQuery1.SQL.Text:='INSERT INTO....';
ZQuery1.ExecSQL;

ZQuery1.SQL.Text:='SELECT LAST_INSERT_ID()';
ZQuery1.Open;
myData.FID:=ZQuery1.Fields[0].AsInteger;

Ist connectiongebunden und somit für die jeweilige Aktion auch immer eindeutig - sprich, es kann dir bzgl. der ID keiner dazwischenfunken.

Gruß Igotcha

[Daniel]

Heißen Dank. :-) Das werde ich heute Abend gleich mal ausprobieren. In meinem Fall bin ich so oder so der einzige, der auf der DB herumfummelt.

[alzaimar]

Zitat:

Zitat von Delami

Ich finde das mit den AutoID auch immer ein elendes Gefummel, und letztlich benutze ich dann das, was immer geht. Ich erzeuge einen neuen Datensatz der z.B. als Nachnamen '999999' enthält. Mit 'select * from meineTabelle where NachName='999999''. Jetzt habe ich die ID und kann NachName neu vergeben. Nicht elegant aber geht... :gruebel:

Das ist aber ziemlich ineffizient.

Wenn man z.B. eine anwendung entwickelt, die (einigermaßen) DB-unabhängig sein soll, dann muss mein seine Zähler selbst verwalten:
Eine Tabelle ('TableID') enthält zwei Spalten: (TabellenName, NextID). Dort steht für jede Tabelle die nächste zu vergebende ID drin.

Wenn ein neuer Datensatz erzeugt wird, kapsle ich das in einer Transaktion: Erst den Wert aus der TableID-Tabelle holen, den entsprechendend Record um 1 erhöhen und dann die ID in meine Zieltabelle eintragen.

Vorteil: Plattformunabhängig.
Nachteil: Etwas lahm

Wie das nunmal so ist.

[Memo]

So praktisch wie diese Funktion

SQL-Code:

'SELECT LAST_INSERT_ID()'

ist hat sie sich in einem Projekt von mir als ausgemachte Bremse herausgestellt. Je grösser die Tabelle wurde umso langsamer wurde es.


Mit

SQL-Code:

SELECT MAX(id) from ...

ging es dann wieder sehr schnell.

Zitat:

Ist connectiongebunden und somit für die jeweilige Aktion auch immer eindeutig - sprich, es kann dir bzgl. der ID keiner dazwischenfunken.

Das ist der einzigste Nachteil wenn man mit "Max" arbeitet. Aber wenn Daniel der einzigste ist der an der DB fummelt..

[alzaimar]

Zitat:

Zitat von Memo

So praktisch wie diese Funktion

SQL-Code:

'SELECT LAST_INSERT_ID()'

ist hat sie sich in einem Projekt von mir als ausgemachte Bremse herausgestellt. Je grösser die Tabelle wurde umso langsamer wurde es.


Mit

SQL-Code:

SELECT MAX(id) from ...

ging es dann wieder sehr schnell.

Zitat:

Ist connectiongebunden und somit für die jeweilige Aktion auch immer eindeutig - sprich, es kann dir bzgl. der ID keiner dazwischenfunken.

Das ist der einzigste Nachteil wenn man mit "Max" arbeitet. Aber wenn Daniel der einzigste ist der an der DB fummelt..

Echt, MySQL? :wall:

[Memo]

Zitat:

Echt, MySQL? :wall:

Ja, echt.

[Luckie]

Wäre es nicht zu überlegen das Konzept zu ändern? Ich sehe die AutoID wie ein Handle. Es dient dazu intern für die Datenbank einen Datensatz eindeutig zu identifizieren. Der Wert sollte dabei dabei keine Rolle spielen und ist eigentlich vollkommen uninteressant.

[Daniel]

Der konkrete Wert ist mir auch egal - nur wenn ich in weiteren Tabellen darauf Bezug nehmen möchte, ist's halt ganz praktisch. Das Daten-Geflecht muss nur in sich stimmig sein.

Das ist von der Idee her das Gleiche wie mit den Themen-IDs hier im Forum. Die Einträge in der Beitragstabelle beziehen sich darauf.