SQL Automatisch zugeteilte Id ermitteln.

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

[Perlsau]

Klar, wenn man via SQL-Befehlen direkte Inserts absetzt. Arbeitest du jedoch mit einer Datenmenge (Query), mittels derer du einen neuen Datensatz anzulegen gedenkst, nützt dir die Returning-Klausel nichts, denn Query.Append ist eine Procedure.

[Dejan Vu]

Ich muss mein Deutsch verbessern: Was ich meine, ist etwas wie die Property 'AutoGenerateValue' in einem TIntegerField. Normalerweise erzeugt der Provider einen Befehl, à la:

Code:

INSERT INTO Foo (ID,Value) VALUES (0,'Bar')

Der weiß doch nicht, das ID ein AutoInc-Feld ist. Erst wenn ich die o.g. Property entsprechend setze, wird der Befehl anders gerendert:

Code:

INSERT INTO Foo (Value) VALUES ('Bar') RETURNING ID

ADO kann die 'AutoGenerateValue' selbst richtig setzen, weil ja aus der Schemainformation (zumindest im SQL-Server) hervorgeht, das ID eine IDENTITY-Spalte ist. Nur, woran erkennt der Provider nun, das das Feld 'ID' bei Firebird eine Art AutoInc-Feld ist? Er wird ja wohl kaum die Trigger parsen...

[Perlsau]

Wenn deine Datenbank AutoInc in irgend einer Form unterstützt (bei Firebird z.B. über AfterInsert- bzw. BeforeInsert-Trigger und entsprechendem Generator) benötigst du keine clientseitige Initialisierung dieser Funktionalität, denn der Trigger löst automatisch beim Insert aus, und zwar völlig unabhängig vom Provider oder dem Sender des SQL-Befehhls.

Unterstützt dein DBMS das nicht, bieten einige DB-Komponenten die Möglichkeit, das via Client zu erledigen. Die entsprechenden Einstellungen zu wählen ist Aufgabe des Entwicklers. Der Provider muß nicht "wissen", ob es sich um ein "AutoInc-Feld" handelt.

Und ja: Kommuniziert man über Sachgebiete, die exakte Darstellungen erfordern (wie beispielsweise Mathematik oder eben auch eine Programmiersprache wie Pascal), ist es nicht wirklich zielführend, weiterhin die gewohnte Umgangssprache einzusetzen. Ohne ausreichende Kenntnis der Fachbegriffe und ihrer Bedeutung versagt man dann regelmäßig beim Versuch, Sachverhalte korrekt darzustellen.

[Uwe Raabe]

Zitat von Dejan Vu:

Nur, woran erkennt der Provider nun, das das Feld 'ID' bei Firebird eine Art AutoInc-Feld ist? Er wird ja wohl kaum die Trigger parsen...

Aus diesem Grund gibt es ja TAutoIncField bzw. den DataType ftAutoInc . Der Provider muss das nur passend zum Server umsetzen. Nicht alle können bzw. machen das. DbExpress hat da so seine Problemchen während FireDAC das ganz gut hinkriegt.

[mkinzler]

Das RETURNING von FireBird wird ihm be der Verwendung von MySQL wenig bringen. In diesem Fall würde ich mich auch nicht darauf verlassen, dass der Datensatzzeiger nach dem Insert aauf dem richtigen Datensatz steht, sondern wie in der 1. Antwort beschrieben die saubere Variante wählen.

[DeddyH]

Das RETURNING hatte ich erwähnt, als von Firebird die Rede war. Weshalb man unter MySQL LAST_INSERT_ID verwenden sollte, ist in dem verlinkten Artikel aus der ersten Antwort erschöpfend beschrieben.