Wie fortlaufende Nr. in DB-Taballe erzeugen? Generator nicht möglich?

[jobo]

Ich denke auch, dass man hier aufpassen muss, nichts durcheinander zu werfen.
Das beginnt damit, wie die (fachliche?) Anforderung für die aufsteigende, lückenlose Konto abhängige Buchungsnummer begründet ist bzw. in der Praxis verwendet wird.
Das ist zu trennen von der technischen Anforderung nach einem eindeutigen Schlüssel für die Buchung, die
a) sicher ohne probleme über einen Generator (Sequence) abzuwickeln ist
b) so oder so transaktionssicher (auch ohne Table Lock!) funktioniert
c) prinzipbedingt Lücken hinterlassen kann
d) table lock kann in belasteten Umgebungen drastische Performanceprobleme mit sich bringen

Wenn die technischen Anforderungen also mit einem Generator unproblematisch zu erfüllen sind (was wahrscheinlich so ist), dann hat man vielleicht nur noch ein Darstellungs(!)problem für die Buchungsnummern.

Das Darstellungsproblem könnte man glaub ich auch unter Firebird als zusätzliches Feld über die Rankfunktion virtuell erzeugen, on the fly, also immer lückenlos, weil frisch generiert, auch wenn mal alle Buchungen in die Tonne kommen sollten.
Hab grad nicht ganz klar, ob das schon unter 2.5 so da ist, oder erst unter V 3.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1279143)

Das Darstellungsproblem könnte man glaub ich auch unter Firebird als zusätzliches Feld über die Rankfunktion virtuell erzeugen, on the fly, also immer lückenlos, weil frisch generiert, auch wenn mal alle Buchungen in die Tonne kommen sollten.

So eine Buchungsnummer ist immer auch ein Schlüssel. Bei Rechnungsnummern hast Du ja das gleiche Problem. Die müssen ja auch lückenlos sein.
Das Performanceproblem kann man auch über bulk inserts umgehen, falls der use case in der Praxis auftaucht.

[mjustin]

Zitat:

Zitat von Dejan Vu (Beitrag 1279144)

So eine Buchungsnummer ist immer auch ein Schlüssel. Bei Rechnungsnummern hast Du ja das gleiche Problem. Die müssen ja auch lückenlos sein.

Wie ist "Lücke" definiert?

Zitat:

Die Rechnungsnummern dürfen also je nach Kunden oder Produkten unterschiedlichen Text enthalten. Sie brauchen nicht lückenlos aufeinander zu folgen.

Erlaubt sind zum Beispiel folgende Rechnungsnummern:

2008.25.0167
Interkauf-1267.10.08
10875-web-345-08

http://www.steuer-schutzbrief.de/ste...alig-sein.html

[Dejan Vu]

Lücke ist '1,3,4' statt '1,2,3'.
Rechnungsnummern müssen wirklich nicht fortlaufend sein, sollten es aber. Und es erspart viel Arbeit bei Buchprüfungen. Davon hatte ich schon zwei, und Prüfer lieben fortlaufende Rechnungsnummern. Klar kann man Rechnungsnummern, die man dem Finanzamt nicht melden will, über einen separaten Kreis erstellen. Aber nach die Prüfer (denen ich meine Idee mit dem separaten Kreis nicht mitgeteilt habe, um Verzögerungen zu vermeiden), meinten eben: 'Hättste mal, dann wären wir' (eher fertig).

Aber zurück zum Thema: Auch bei Buchungsvorgängen ist es einfach sinnvoll, die Buchungsnummern fortlaufend zu haben. Und zwar aus Nachweisgründen. Klar, in einer Datenbank geht selten etwas verloren, aber es ist einfach sicherer, hier eine fortlaufenden Nummerierung zu haben.

[dataspider]

Hi,

für die Buchungsnummern würde ich eine eigene Tabelle erzeugen.
Man könnte die Nummer zwar auch im Konto speichern, aber wenn man später die Vergabe z.B. abhängig vom Jahr machen will, baut man wieder um.

Also eine Tabelle Buchungsnummer mit den Feldern KONTO, JAHR, NUMMER.

Im Projekt vor dem Post eine PROCEDURE aufrufen, welche mit den Parametern KONTO, JAHR die Nummer zurück liefert.
Diese Procedure legt auch die Datensätze in BUCHUNGSNUMMER an bzw. zählt die Nummer hoch.

Im Code dann eine Methode GetBuchungsnummer in etwa so (Ist jetzt IBO und Barcode, aber kann man ja anpassen):

Delphi-Quellcode:

function TdmMain.NaechsteBarcodeNummer(ZaehlerId: Variant): string;
Var
  I: Integer;
begin
  Result := '';
  if not spBarcodeNummer.Prepared then
    spBarcodeNummer.Prepare;
  spBarcodeNummer.Params[0].Value := ZaehlerId;
  try
    for I := 1 to 10 do
    begin
      Sleep(500);
      try
        spBarcodeNummer.ExecProc;
        result := spBarcodeNummer.Fields[0].AsString;
        spBarcodeNummer.IB_Transaction.Commit;
        spBarcodeNummer.Unprepare;
        Break;
      except
        spBarcodeNummer.IB_Transaction.Rollback;
      end;
    end;
  finally
    if spBarcodeNummer.Prepared then
      spBarcodeNummer.Unprepare;
  end;
end;

Bei Lock Konflikt wird eine Exception ausgelöst und es wird insgesamt 10 mal ausgeführt.
Ich habe das getestet in einee MINI - Anwendung, die nur Nummer geholt hat und habe das mehrmals auf meinem PC gestartet.
Ich habe mehrere 1000 Nummern erzeugt und in einer Liste gespeichert.
Der eine Prozess hatte dann 100, 101, 103, der andere 99, 102, 104.

Ich werde sicher kritisiert wegen der Lösung mit eine stillen Exception.
Ich hatte es vorher mit einer Transaktion mit LOCK_WAIT getestet, da hatte aber IBO Probleme.

Wichtig, die PROCEDURE muss eine eigene Transaction bekommen und wenn es mit LOCK_WAIT funktioniert, braucht man die Schleife nicht.

Frank