Firebird: Generator mit dynamischen Namen

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

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

[Hansa]

Zitat von mkinzler:

Ohne expliziten Lock der Tabelle könnte es passieren, dass 2 gleichzeitige Vorgänge 2 identische Nummern generiert!

Da passiert eben nichts. Ich will ja nicht streiten oder Spocki Vorschriften machen, aber Transaktionskontrolle muss sein. Ich habe umfangreiche Tests durchgeführt. Sowohl für diese Recnr-SP als auch für normale Datensätze, also Updates über Delphi-Programm. 3 Rechner : der erste speichert so schnell er kann. Der zweite lässt sich eine Sek. Zeit, der dritte sogar 2 Sek. Das Ganze übers Wochenende. Bei dem Table-Update habe ich dafür gesorgt, dass die 3 Rechner nur auf drei Datensätze Updates gemacht haben. Nach menschlichem Ermessen und einem nicht wasserdichten System hätte da bei über 60 St. Laufzeit irgendwo ein Konflikt auftauchen müssen. Zumindest sind sie sich wohl schon irgendwo ins Gehege gekommen. Sonntag mittags hat mich dann die Neugier gepackt und was war ? Kein Fehler, nichts. Das mit dem Lock, das scheint überflüssig zu sein.

Hat mich dann auch nicht gewundert, dass Montag morgens immer noch nichts war. Firebird geht schon gut. Für Netzwerk ist nur wichtig : richtige Transaktionskontrolle.

[mkinzler]

Vielleicht nur Glück oder durch das verwendete MP bedingt. Ich würde das aber an Deiner Stelle ändern, denn ab FB3 könnte das dann schön in dei Hose gehen.

[Dejan Vu]

Also bei einer derartigen Konstellation würde ich wirklich empfehlen, eine eigene Funktion dafür zu schreiben. Anhand einer Hilfstabelle werden die Zähler verwaltet. Da das Ganze eh in einer Transaktion ausgeführt wird, sind Dopplungen ausgeschlossen.

Wenn Du einen Generator verwendest, machst Du dich imho implizit von der Implementierung des Generators abhängig bzw. von etwaigen Restriktionen. Das ist zwar hier nicht der Fall, aber unsauber. Finde ich.