Autowerte bei Firebird setzen

[Albi]

Hallo,

dann schaue Dir mal die Feldbeschreibung an. Da wirst Du sehen, dass der Primary Key gesetzt wurde, sich die Datenbank also die Einstellung gemerkt hat. Wenn Du beim anlegen der DB halt AutoInc auswählst, ist das wohl das gleiche wie der Primary Key. Also ein eindeutiger Schlüssel, der nur einmal vorkommt.

Ob Du nun diesen Schlüssel selber erstellst oder über einen Trigger dies machen lässt, bleibt im Grunde dir überlassen.

Ich habe habe das Feld AutoInc im IBExpert nur gesehen, wenn du die Table bzw. das Feld anlegst, danach ist es wie schon gesagt nur über die Feldeigenschaften zu erkennen, in welchem Verhältnis was zu wem steht. Hast Du das Feld vielleicht mit dem "Not Null" verwechselt?

[Robert_G]

Zitat von marabu:

Ich habe immer einen solchen Trigger - und benutze ihn dann nicht. Der Trigger dient bei mir nur der Unterstützung von bulk-load Operationen. Den ID für single record inserts hole ich mir vom Generator und setze ihn in der Anwendung. Auf diese Weise habe ich die ID für meinen Programm-Kontext. Echte AutoInc-Felder machen bei primary key Feldern mehr Probleme als Freude.

Interssant ist die Geschichte von Interbase. eines der ersten "Features", die Borland in IB nach der Übernahme "eingebaut" hatte, war das Entfernen von rüggabewerten aus DML Statements...
Seitdem muss man tatsächlich so vorgehen, wie du es beschrieben hast. In Ora mache ich es meist so:

Delphi-Quellcode:

create or replace trigger X_PkTrig
 before INSERT or UPDATE ON SomeSchema.X 
 -- rename New and Old, they could be used as table or column names ...
  REFERENCING New AS New$Rec Old AS Old$Rec
  for each row
begin
  if Inserting then
    -- get next value from sequence
    SELECT SomeSchema.X_PkSeq.NextVal
    INTO   :New$Rec.ID
    FROM   dual;
  elsIf Updating then
    -- prevent changes of ID
    :New$Rec.ID := :Old$Rec.ID;
  end if;
end SomeSchema.X_PkTrig;

Die ID bekomme ich so:
insert into X (a,b) values (:a,:b) returning id into :id; Wenn man die Cache size der sequence passend wählt macht es sich auch in großen bulk inserts nicht wirklich bemerkbar.
Das schöne an der Methode ist, dass ich sie komplett automatisch ablaufen lassen kann. (Also die Erzeugung von Trigger/Sequence)

btw: Seit wann kann FB Bulk DML?

[FBrust]

Hallo Albi,

Zitat:

Ich habe habe das Feld AutoInc im IBExpert nur gesehen, wenn du die Table bzw. das Feld anlegst, danach ist es wie schon gesagt nur über die Feldeigenschaften zu erkennen, in welchem Verhältnis was zu wem steht. Hast Du das Feld vielleicht mit dem "Not Null" verwechselt?

Nein, ich hab "not null" zusätzlich ausgewählt, es gibt ja beides bei der Felderstellung. Ich war es halt vom ADS und von der BDE so gewohnt, dass man ein Feld als "Autoinc" definiert und ab dann kümmert sich die Datenbank um das Hochzählen, ob das Feld Primary key war oder nicht.

Nun, wie gesagt, ich bau dann eben einen Trigger ein.


Gruß
Frank

[mschaefer]

Moin, Spätmoin

Zitat:

Den ID für single record inserts hole ich mir vom Generator und setze ihn in der Anwendung

Das ist eigentlich das leidige an Zeos, das es sich hier nich tselbst drum kümmert. Wenn man die ID nicht selbst holt und in das Primärindexfeld schreibt verliert der Dataset den aktuellen Record nach einem Post. Das gibt in einem Grid dann seltsame Sprünge. Bisher habe ich das so gelöst, das ich im Before-Iinsert-Ereignis mir eine Query auf den Generator gesetzt habe und den neuen Generatorwert dann vor einem Post eintrage. Wenn ein Zeos-Entwickler hier mitliest, dann überdenkt hier doch mal eine automatisierung.

Grüße // Martin

[Robert_G]

Zitat von mschaefer:

Moin, Spätmoin

Zitat:

Den ID für single record inserts hole ich mir vom Generator und setze ihn in der Anwendung

Das ist eigentlich das leidige an Zeos, das es sich hier nich tselbst drum kümmert. Wenn man die ID nicht selbst holt und in das Primärindexfeld schreibt verliert der Dataset den aktuellen Record nach einem Post. Das gibt in einem Grid dann seltsame Sprünge. Bisher habe ich das so gelöst, das ich im Before-Iinsert-Ereignis mir eine Query auf den Generator gesetzt habe und den neuen Generatorwert dann vor einem Post eintrage. Wenn ein Zeos-Entwickler hier mitliest, dann überdenkt hier doch mal eine automatisierung.

Grüße // Martin

Warum leitest du nicht einfach von dem DataSet ab.
Verpasse ihm eine Eigenschaft mit dem Generatornamen, überschreibe OnBeforePost und gut ist.

[mschaefer]

Tach Robert,

ja - genausowas habe ich dann auch gemacht (muß ja nicht gleich mit der Tür ins Haus fallen), aber leider muß ich jetzt immernoch bei jedem Dataset den SQL-Befehl für das holen des Trickers extra eintragen. Im Moment habe ich eine zusätzliche StringListe mit der Generator-Abfrage die im BeforePost über ein temporäres Dataset abläuft...

Mir ist es also nich gelungen, daß so zu verallgemeinern, daß man einfach eine Eigenschaft GetGeneratorrBeforePost auf True setzt und gut. Das ist leider nervig.

Grüße // Martin

[Robert_G]

Ich hoffte, dass vielleicht noch ein paar mehr Infos kommen würden...

Ehrlich gesagt hoffe ich, dass ich das falsch verstanden habe.

Zitat von mschaefer:

ja - genausowas habe ich dann auch gemacht (muß ja nicht gleich mit der Tür ins Haus fallen), aber leider muß ich jetzt immernoch bei jedem Dataset den SQL-Befehl für das holen des Trickers extra eintragen. Im Moment habe ich eine zusätzliche StringListe mit der Generator-Abfrage die im BeforePost über ein temporäres Dataset abläuft...

Genau hierum gates.

Zitat von mschaefer:

Mir ist es also nich gelungen, daß so zu verallgemeinern, daß man einfach eine Eigenschaft GetGeneratorrBeforePost auf True setzt und gut. Das ist leider nervig.

Nur um ein paar Ansätze in den Raum zu werfen.

• Eine *piep*-normale string Property, die den Namen des Generators enthält.
  Im OnBeforeXXX wird sich dann der neue Wert aus diesem Generator geholt, falls ein Name eingetragen wurde.
• Wieder diese Property, doch nun mit einem Property Editor, der alle Generatoren auflistet, die in Triggern verwendet werden, die den PK der Tabelle aus dem SELECT Statement verwenden.
  FB sollte hierfür System views anbieten, die Abhängigkeiten abbilden.
  Gibt es Extra Statements für DML? Wenn ja, dann natürlich für's INSERT Statement. (Sorry, ich habe Zeos ewig nicht angerührt...)
• Das könnte man soweit treiben, dass beim Ändern des SQL Strings automatisch der Generator geholt wird, wenn nur einer ins Suchmuster passt (was wohl in 99% aller Fälle auch der Fall sein wird )
  Der letzte Teil sollte vielleicht über eine bool'sche Property laufen, da man sicher nicht ständig nach Generatoren suchen lassen will. Wobei man hier natürlich auch gegen SQL.UpdateCount prüfen sollte.

Das Ganze sollte IMHO im erträglichen Rahmen bleiben. (Also vom reinen Code Umgfang...)

[Hansa]

Zitat von Robert_G:

...Wieder diese Property, doch nun mit einem Property Editor, der alle Generatoren auflistet, die in Triggern verwendet werden, die den PK der Tabelle aus dem SELECT Statement verwenden. FB sollte hierfür System views anbieten, die Abhängigkeiten abbilden...

...und womit keiner richtig was anfangen kann. 8) Was soll denn der Firlefanz da ? Ich fange doch nicht an, mir die einzelnen Trigger selber zusammenzusuchen. Für die Vergabe von IDs ist nur der Trigger zuständig, sonst keiner ! Eventuell ist ein falsch gesetztes Commit verantwortlich, wenn es nicht läuft, wie gewünscht. Ich bin jetzt auch einer, der zu unterscheiden weiß, ob irgendwas besser direkt in der DB genacht werden sollte oder im Programm. Die Vergabe der ID gehört in diesem Zusammenhang aber eindeutig in die DB.

[Robert_G]

Zitat von Hansa:

...und womit keiner richtig was anfangen kann. 8) Was soll denn der Firlefanz da ? Ich fange doch nicht an, mir die einzelnen Trigger selber zusammenzusuchen.

Verdammt nochmal... Lerne Lesen, Hansa! Lesen, Nachdenken und VERSTEHEN!
Nur weil DU es nicht kapierst musst du nicht alle anderen als Vollidioten abstempeln.

Zitat von Hansa:

Für die Vergabe von IDs ist nur der Trigger zuständig, sonst keiner !

Da sind wir ausnahmsweise mal einer Meinung. Dummerweise sieht es FB anders. Siehe mein INSERT Statement weiter oben. Um es durch den Trigger abhandeln zu können bräuchte man Rückgabewerte aus DML, die FB nicht kennt.

Zitat von Hansa:

Ich bin jetzt auch einer, der zu unterscheiden weiß, ob irgendwas besser direkt in der DB genacht werden sollte oder im Programm. Die Vergabe der ID gehört in diesem Zusammenhang aber eindeutig in die DB.

Da sind wir wohl eindeutig getrennter Meinung, wobei der letzte Satz auf ein DBMS <> IB/FB zutrifft.

Wie man eindeutig zwischen den Zeilen herauslesen kann, steht mir deine arrogante Art, anderen deine Unwissenheit bekannt zu tun, mal wieder bis Oberkante Unterlippe. Wenn du in dem Thread weiter rumpupst vergeht mir ziemlich schnell die Lust daran.

Ich glaube aber, dass das schade wäre. Denn man könnte hier sicherlich einige stupide Codezeilen und Nerven einsparen.

[Hansa]

Zitat von Robert_G:

...Wie man eindeutig zwischen den Zeilen herauslesen kann, steht mir deine arrogante Art, anderen deine Unwissenheit bekannt zu tun,...

Der Titel des Oberschlaumeiers gehört eindeutig dir. Leider reicht es nun aber nicht aus, mit ein paar Wörtern um sich zu schmeißen, die Leute zu verwirren und im Grunde genommen nichts zu sagen. Sorry, aber das ist einfach zuwenig.