Firbird Generator und Transaction

[TurboMagic]

Zitat von IBExpert:

in Firebird ist das per Generator einfach lösbar aber nur als eindeutige werte, lückenlos muss man anders machen, geht aber eigentlich
auch einfach.

Jetzt spannst du uns aber auf die Folter

[Billa]

Ein (schon sehr alter) Ansatz für numerierte Belege :

Man speichert eine gewisse Anzahl Nummern mit Hilfe des Generators in einen "Vorrat".
Von dort holt man sich bei Bedarf für seine Transaktion die niedrigste ungesperrte Nummer und sperrt sie im Vorrat.

Wird Transaktion abgebrochen, hebt man einfach die Sperre wieder auf. Ansonsten wird die Nummer entfernt. Ein Trigger sorgt dafür, dass immer genug ungesperrte Nummern vorrätig sind. 50 Nummern waren bei nur drei Clients immer genug.

Dann ist die Folge der Nummern lückenlos, aber nicht zwingend chronologisch. Die Reihenfolge kann bei längeren Transaktionen durch Abbruch vertauscht sein. Das war für die damalige Aufgabenstellung aber nicht wichtig und wurde durch einen zusätzlichen Zeitstempel kenntlich gemacht.

Alternativ kann man statt zu sperren auch die Nummer sofort aus dem Vorrat entfernen und bei Abbruch der Transaktion wieder dort einfügen.

Wahrscheinlich gibt es aber noch bessere Methoden.

[tkhandel]

Hallo,

eine spannende Diskussion die ich da losgetreten habe.
Ich habe aber eine ganz einfache Situation, da ich nur einen User an einer Kasse habe und die Kassen abends nur Ihre Daten übertragen und am
nächsten Tag wieder bei 0 anfangen( ausser die BON Nr die muss eben an jeder Kasse für sich weitergezählt werden).
ist ein Generator die sicherste Lösung.

Da ja keine zwei User eine Kasse bedienen können habe ich da mal über eine procedure gelöst die ich aufrufe wenn
der Kassiervorgang abgebrochen wurde.


SET TERM ^ ;

create or alter procedure PROC_BONGEN_DEC (
IST_ZAEHLER integer)
returns (
SOLL_ZAEHLER integer)
as
begin
ist_zaehler = GEN_ID( gen_bon_id, 0 );
Soll_Zaehler = (ist_zaehler - 1);
if (soll_zaehler >0) then
begin
ist_zaehler = gen_id(GEN_BON_ID, -(gen_id(Gen_Bon_Id, 0)));
soll_zaehler = gen_id(Gen_Bon_Id, :soll_zaehler);
end
suspend;
end^

SET TERM ; ^

Gibt es was das da gegen spricht ?

[MyRealName]

Kannst Du eine nicht genutzte Nummer einfach als annuliert führen ? SO haben wir das in Kolumbien lösen können, da wird das vom Finanzamt scheinbar erlaubt (sagte mein Chef)

[tkhandel]

Ich hatte das in einer Multiuser-Umgebung so gelöst, das ein erzeugter Beleg beim abrechen (automatisch) wurde, also
ein neuer Stornobeleg zum Ursprungsbeleg erzeugt wurde, das ist die einfachste Lösung da es nun ja nicht so oft vorkommt
und nach der Umstellung beim Kunden noch weniger wie vorher.

Bei Kassensystemen ist das nun eigentlich generell auch so das ein Beleg storniert werden muss um die
Nachvollziehbarkeit eines Kassenvorgangs zu gewährleisten zumal ja auch noch Positionsdaten des ersten Artikel
in der TSE gespeichert werden.

[IBExpert]

wenn multiuser eh kein problem bei dir ist, dann ermittel die nächste nummer mit

select coalesce(max(nummer),0)+1 from tabelle where datum=current_date

mit einem desc index auf der nummer und dem datumsfeld (falls erforderlich weil datensätze von gestern in der tabelle bleiben)
geht das auch sehr schnell

wenn es eh bei 0 wieder losgeht ist der umweg über generator im singleuser mode unnötig kompliziert

[tkhandel]

Hallo Holger,
ich hatte mich falsch oder besser gesagt Blöde ausgedrückt.
Die BON-Nr muss natürlich immer fortlaufend sein, deshalb der Generator bei der BonNr.
Ich hatte nur das Problem das ein Rollback alles zurück setzt nur den Generator nicht.