Firebird: Generator mit dynamischen Namen

[Lemmy]

Zitat von MrSpock:

danke für die Info. Hast du eine Ahnung, warum diese Warnung ausgesprochen wird?

Ich denke aus dem selben Grund weshalb man bei Firebird (und anderen) nicht in den Systemtabellen manuell rumwursteln soll:
Weil Dinge schief gehen können. Das Beispiel mit dem Messer ablecken finde ich sehr treffend

Beispiel: Kollege wollte einen Float vergrößern (Numeric 4,3 auf 6,4) - und weil es schnell gehen musste und man auf die schnelle den Befehl nicht auswendig kannte, griff man die Systemtabellen an und hat Länge und Genauigkeit verwechselt - mit dem Erfolg dass nach dem "Update" nichts mehr ging: Keine Datensicherung, Programm nicht mehr usw....

Mit einem Alter Domain wäre man gar nicht in Versuchung geraten die Zahlen falsch rum einzutragen und wäre zudem von den Firebird-Internas geschützt geworden.

Aber: Keine Frage, dass in manchen Situationen der Zugriff auf die Systemtabellen hilfreich ist....

Ich würde jetzt auch nicht annehmen, dass die Erstellung von Generatoren durch eine StoredProcedure Probleme nach sich zieht, aber ich denke das Konzept ist dennoch nicht gut, weil die Anzahl der Generatoren in Firebird begrenzt ist:

http://www.firebirdsql.org/manual/de...sqlsyntax.html

auch dann, wenn es aktuell danach aussieht, dass die gut 600 Jahre ausreichen würden.

[mkinzler]

Ab FireBird 3 kann man die Systemtabellen nicht mehr direkt manipulieren.

[jobo]

Ich verstehe den Sinn nicht, ein aufrufendes Programm (oder auch Trigger) muss dann ebenfalls noch umgeschrieben werden, um den neuen Generatornamen zu beherrschen?
Wenn schon dynamisches DDL, warum dann nicht ein Drop bzw. Reset des bestehenden Generators unter gleichem Namen?

[MrSpock]

Hallo jobo,

weil der User auch nachträglich noch in eine vorherige Erfassungswoche wechseln kann. Im Moment benutzt das Programm eine ini-Datei, umden aktuellen Wert der Erfassungsnummer pro Woche/Jahr einzulesen und zu speichern. Das Programm läuft seid fast 10 Jahren so ohne Probleme. Der Kunde möchte jetzt aber Mehrbenutzerbetrieb und da will ich die Nummer durch die DB erzeugen lassen.

[jobo]

Zitat von MrSpock:

weil der User auch nachträglich noch in eine vorherige Erfassungswoche wechseln kann.

Ok, wenn das nicht verkürzt dargestellt ist, wären eigentlich nur 2 Generatoren nötig.

Wäre es nicht am hübschesten, eine Funktion zu definieren, die das anhand eines Datumsparameters (oder KW Parameter) richtig ausspukt?

Zu dem Zitat von Jumpy:
Ich kann nur eine Idee anhand des Verhaltens von Oracle geben. Hier ist es so, dass DDL implizit ein Commit durchführt. Wenn also innerhalb ein Oracle Code Blocks ein DDL Statement aufgerufen wird, passiert "nichts schlimmes" außer halt ein Commit.
Wenn alles gut geht ist es wunderbar, wenn nicht hat man ein riesen Problem, weil ein Fehler oder ein explizites Roleback nur noch einen Teil der Transaktion zurückdreht. Vielleicht ist es bei FB ähnlich.
Deswegen gibt es diese Regel bei uns intern genauso wie bei Firebird. Wer erwischt wird, muss stramm stehen und sich wüßt beschimpfen lassen, bekommt die Haare abrasiert (wenn er noch keine Glatze hat) und muss für die Kollegen eine Woche Kaffee ausschenken.

[Hansa]

Die Warnung ist doch klar : ein Generator eignet sich in keinster Weise dazu, Informationen ausser dem Generatorwert an sich, zu speichern. Es gibt noch nicht mal Transaktionssteuerung. Den lässt man einfach laufen und sonst in Ruhe. Hier wird jetzt versucht, dem Generator über seinen eigenen Namen irgendwelche Zusatzinformationen zu verschaffen.

Hier wurde auch schon mal empfohlen, einen Generator zur Erzeugung von fortlaufenden Nummern zu erzeugen. Das geht in ähnliche Richtung. Die Nr. kann ich doch auch in Tabelle speichern. Da steht dann eben nur ein Datensatz drin mit der Rechnungsnummer. Wen interessiert das denn ? Ich kann dann zumindest mal eine total falsche Rechnung schreiben, merke das, mache ein Rollback und fertig. Über Generator müsste ich die Datenbank umschreiben.

Roter Kasten sagt gerade : Mehrplatzbetrieb ! Um Gottes Willen, dann dreimal Finger weg von Generatoren ! *haarsträub*

[mkinzler]

Zitat:

Mehrplatzbetrieb ! Um Gottes Willen, dann dreimal Finger weg von Generatoren ! *haarsträub*

Mehrplatzbetrieb ist kein Problem für Sequenzen, wen GEN_ID() verwendet wird.

[Hansa]

Zitat:

Mehrplatzbetrieb ist kein Problem für Sequenzen, wen GEN_ID() verwendet wird.

So meine ich das nicht. GEN_ID verschafft doch keine Transaktionssteuerng für einen Generator. Für Mehrplatz wird aber eine vernünftige Transaktionssteuerung gebraucht. Ansonsten fliegt einem bei jeder Gelegenheit die DB um die Ohren. Was ist denn wenn zwei Benutzer den gleichen Datensatz zur selben Zeit ändern oder löschen wollen ? Mit der richtigen Einstellung der Transaktions-Parameter lässt sich das schnell richtig realisieren. Zur erstbesten Gelegenheit die Transaktionssteuerung völlig unnötig zu umgehen ist meiner Meinung nach aber total falsch. Kann zwar gehen, wird aber ziemlich sicher Ärger bringen. Würde mich auch nicht wundern, wenn das in neueren FB-Versionen sogar unterbunden wird.

Mir fällt gerade ein, bei der Diskussion mit den fortlaufenden Rechnungsnummern, das warst ja auch Du, Markus, der Generatoren dafür empfohlen hat. War ähnliche Diskussion wie jetzt hier. Es könnte Spocki vielleicht helfen, statt des empfohlenen Generators genügt zumindest mir folgendes (zwar für Rechnungsnr., dürfte sich aber 1:1 übernehmen lassen, string verwenden o.ä.) :

Code:

CREATE TABLE RECNR (
    NR  INTEGER);

CREATE OR ALTER PROCEDURE RECNR_SP
returns (
    recnr integer)
as
declare variable neuerecnr integer;
BEGIN
  NEUERECNR = -1;
  SELECT NR FROM RECNR INTO :NEUERECNR;
  IF (NEUERECNR < 0) THEN BEGIN
    INSERT INTO RECNR (NR) VALUES (1);
    RECNR = 1;
  END
  ELSE BEGIN
    UPDATE RECNR SET NR = NR + 1;
    RECNR = NEUERECNR + 1;
  END
  SUSPEND;
END^

Kommt ziemlich auf Generator/Trigger raus. In dem Fall hier hat die Tabelle RECNR einen einzigen Datensatz mit der letzten Nr. Mit der SP zähle ich die Nr. immer um 1 hoch und kann sie auch direkt per Delphi verwenden. Im Gegensatz zum Generator kann ich aber auch Rollback usw. machen.