Firebird: Generator mit dynamischen 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.

[p80286]

Zitat von MrSpock:

Hallo Lemmy,

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

aus dem gleichen Grund aus dem man ein Messer nicht ablecken sollte......

Wenn der Kunde diesen Generator will.. ok, wenn er will, trotzdem werde ich das Gefühl nicht los, daß da irgendein Datenbank-Voodoo veranstaltet wird. Meiner Meinung nach sollte ein "ErfassungsStartdatum" das vom Benutzer eingegeben/bestätigt wird, ausreichen um die Akte/den Vorgang in die richtige Woche zu verschieben.

Gruß
K-H

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

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

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

[mkinzler]

Zitat:

Für Mehrplatz wird aber eine vernünftige Transaktionssteuerung gebraucht.

Sicher, aber was hat das mit Generatoren zu tun?

Zitat:

Was ist denn wenn zwei Benutzer den gleichen Datensatz zur selben Zeit ändern oder löschen wollen ?

Was hat das mit Generatoren zu tun?
Rechnungsnummern sind etwas anderes als IDs. Aber auch bei Rechnungsnummern sind Lücken kein Problem. Die GEN_ID()-Funktion wird durch eine Semaphore implementiert und stellt somit sicher, dass die selbe Nummer 2mal erstellt wird.
Was bei Deiner Methode nicht der Fall ist! Ohne expliziten Lock der Tabelle könnte es passieren, dass 2 gleichzeitige Vorgänge 2 identische Nummern generiert!

[MrSpock]

Eben wegen der Semaphore bei GEN_ID() möchte ich diese ja als Zähler benutzen. Der Zähler beginnt jeder Woche/Jahr wieder bei 1 und GEN_ID() verhindert die doppelte Vergabe. Ich könnte jetzt z.B. 53 Zähler für die Kalenderwoche einsetzen und diese nach einem Jahr zurücksetzen. Dann müsste ich aber auch noch eine Fehlermeldung ausgeben, wenn jemand versucht eine Erfassung mit einer Erfassungswoche versucht, die mehr als 52 Wochen her ist, weil ich den Zählerstand nicht mehr habe. Oder ich müsste das die Erfassungsnummer manuel ermitteln, indem ich die letzte Nummer der Wochen/Jahr Kombination auslese. Wenn dann durch Mehrfachzugriff genau in diesem Moment zweimal dieselbe ERFNR ermittelt wird, soll der Nutzer das Einfügen des Datensatzes einfach noch einml versuchen.

Wobei ich in 10 Jahren etwa 530 Zähler erzeugen würde, wenn ich meinem ursprünglichen Ansatz treu bleibe. Und nach 100 Jahren könnte man ja auch die DB Generatoren einmal aufräumen.