SQL Automatisch zugeteilte Id ermitteln.

[Bladefire]

Hallo,

Ich möchte ein Programm machen das etwas in eine SQL Datenbank schreibt. Der Datensatz bekommt automatisch von der Datenbank eine id zugeteilt. Nun möchte ich diese Id meinen Programm irgendwie mitteilen.

Jedoch weiß ich nicht wie ich das machen soll.

- ich kann nicht einfach den letzten eingetragenen Datensatz auslesen, da es möglich ist, dass ein anderes Programm etwas in der Zwischenzeit in die Datenbank - Tabelle Schreibt.

Wie soll / kann ich dies realisieren?

Lg Simon

[jfheins]

Die meisten Datenbanken haben dafür eine Funktion wie LAST_INSERT_ID oder ähnliches.

[Perlsau]

@Bladefire:

Gleich nach dem Posten bzw. Insert ist der bearbeitete bzw. gerade eingefügte Record der aktuelle Datensatz. Da kannst du doch einfach abfragen, welcher Wert in deinem Id-Feld steht:

AktuelleId := MyDataset.FieldByName('IdFeld').asInteger; Zur Anzeige in der Statusbar mache ich das in den meisten DB-Anwendungen sogar grundsätzlich, und zwar mittels des Ereignisses AfterScroll. Dort wird dann die Id ausgelesen und ein Ereignis generiert, das meien Statusbar aktualisiert.

[dummzeuch]

Zitat von Perlsau:

@Bladefire:

Gleich nach dem Posten bzw. Insert ist der bearbeitete bzw. gerade eingefügte Record der aktuelle Datensatz. Da kannst du doch einfach abfragen, welcher Wert in deinem Id-Feld steht:

AktuelleId := MyDataset.FieldByName('IdFeld').asInteger;

Funktioniert das inzwischen zuverlaessig? Ich erinnere mich, dass ich daran mal verzweifelt bin - das muss irgendwann in den 90ern gewesen sein - und schliesslich eine Tabelle mit IDs eingefuehrt habe, mit einem Datensatz pro Tabelle, in dem die jeweils naechste zu benutzende ID stand. Diesen Record habe ich dann gelockt, ausgelesen, die ID erhoeht und gespeichert. Das funktionierte dann wenigstens. AutoInc Felder funktionierten spaeter dann fuer Access- und MSSQL mal, wenn man Cursor auf clUseServer gesetzt hat. Aber ich habe immernoch im Hinterkopf, dass sie nicht sicher sind. Mein letztes groesseres Datenbank-Projekt ist allerdings schon wieder ein paar Jahre her.

[Perlsau]

Das funktioniert 100 % zuverlässig, zumindest meiner Erfahrung nach, ich kenne das gar nicht anders, und zwar bei allen DBMS, die ich jemals in Verwendung hatte, als da wären:
Firebird, MsSQL, MySQL, ProstGreSQL, MsAccess. Wäre dem nicht so, wären DBMS nicht wirklich einsatzfähig. Ob DBMS vor 20 Jahren unzuverlässig waren, kann ich nicht beurteilen, hatte damals noch nichts damit am Hut. Und wenn du's nicht glaubst, probier's doch einfach mal aus, wirst schon sehen (sollte man sowieso immer machen, wenn man Ratschläge aus Foren erhält).

[Dejan Vu]

Ob das so funktioniert, hängt nicht vom RDBMS ab, sondern vom Provider (Zeus, ADO, dbExpress, DAC) und da gab es -zumindest bei ADO- früher wirklich Probleme bzw. hat das nicht funktioniert. Früher. Jetzt ist das alles kein Problem mehr. Man muss nur sicherstellen, das der Provider erkennt, das es sich um ein AutoInc-Feld handelt bzw. das persistente Feld entsprechend deklarieren. Firebird z.B. kennt keinen AutoInc-Datentypen. Da erstellt man einen Generator und stellt im Provider das Feld entsprechend ein.

[Perlsau]

Mit all den von dir genannten DB-Komponenten funktioniert genau das: Wenn ich einen neuen Datensatz in eine Datensatz-Menge einfüge, bleibt dieser Datensatz der aktuelle, solange ich keinen anderen Datensatz einfüge oder anwähle. Das hat nichts mit Auto-Inc-Feldern zu tun. Im Übrigen gibt es Zeus nicht, das heißt Zeos.

[Dejan Vu]

Ach, Zeos, genau. Ich wollte dir nach widersprechen, sondern nur darauf hinweisen, das es Sache des Providers ist, sich um die Aktualisierung von Daten zu kümmern. Ähnliches gilt ja auch für einen Zeitstempel, der vom Server gesetzt wird, weil man z.B. in einer Spalte den Zeitpunkt der letzten Änderung haben will, und da ist es sinnvoll, die Serverzeit zu setzen (per Trigger). Nun muss aber dieser Wert wieder zum Client...

Und das es der aktuelle Datensatzzeiger ist, liegt daran, das der aktuelle Record eingefügt/aktualisiert wird, wenn ein Post stattfindet. Und das findet bei einem Recordwechsel statt (dann ist der eben noch aktuelle DS zwar nicht mehr aktuell, aber ich weiss ja, was Du meinst), oder man ruft explizit Post auf.

Es gibt ja auch den Modus, das man die Änderungen erst lokal durchführt (für beliebig viele Records) und dann die Änderungen in einem Abwasch zum Server schickt. Dann gibt es ja keinen 'aktuellen' Datensatzzeiger. bzw. gibt es einen, aber es werden auch andere Records aktualisiert.

Wie ist denn die ID-Spalte bei einer Verbindung zu Firebird deklariert, damit sie nach einem INSERT weiß, welche ID vom RDBMS vergeben wurde?

[Perlsau]

Zitat von Dejan Vu:

Wie ist denn die ID-Spalte bei einer Verbindung zu Firebird deklariert, damit sie nach einem INSERT weiß, welche ID vom RDBMS vergeben wurde?

Was meinst du damit? Die Id-Spalte ist in Firebird deklartiert und nicht im Client, der die Verbindung zur FB-Datenbank herstellt, z.B.:

Code:

ID_ZUSATZKLASSE  INTEGER NOT NULL
ALTER TABLE ZUSATZKLASSE ADD CONSTRAINT PK_ZUSATZKLASSE PRIMARY KEY (ID_ZUSATZKLASSE);

Willst du AutoInc-Funktionalität, erstellst du dir einen BeforeInsert- oder AfterInsert-Trigger, der einen Generator aufruft, von dem er sich den neuen Wert holt und in die Id-Spalte einträgt. IbExpert erledigt das automatisch, wenn man beim Erstellen der Tabelle die AutoInc-Checkbox aktiviert.

Vom Client aus kannst du dann – bei BeforeInsert – die Id-Spalte bereits vor dem Posten auslesen. Hast du AfterInsert eingestellt, mußt du dir mit dem Auslesen des aktuellen Generatorwertes behelfen:

Code:

select GEN_ID(GEN_ZUSATZKLASSE_ID,0) from RDB$DATABASE

... wobei der zweite Parameter den Increment-Wert darstellt.

[DeddyH]

Firebird kennt (IIRC ab der Version 2.0) eine RETURNING-Klausel, die genau für solche Zwecke gedacht ist, siehe z.B. hier.