Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[rokli]

Hier noch mal die Ansicht der Daten in der DB als Bild; das ist da oben nicht wirklich gut zu erkennen!

Und alles natürlich in TSQL ... :wink:

[jobo]

Ich habe hier mal einen Versuch gemacht mit einer autarken SP ohne separates Reset des Generators. Da ich wenig Praxis mit FB habe, bitte gut testen. Vielleicht schaut ja auch einer der FB Kenner hier mal drüber.

SQL-Code:

-- create daily cyclic sequence number / expression 

-- table storing last used date
-- drop table rndatebuffer;
create table rndatebuffer (
  isRestricted char(1) Default 'X' unique,          --force one record only
  lastDate date not null ,
  constraint forceOneRow check (restricted='X'));   --force one record only
  
-- insert into rndatebuffer (lastdate) values(CURRENT_DATE-1);
-- select * from rndatebuffer;

-- sequence 
CREATE GENERATOR gen_rn;
SET GENERATOR gen_rn TO 0;


--drop procedure getrn;
--procedure to fetch new "number"
SET TERM ^ ;
CREATE Procedure GetRN RETURNS (prn varchar(20)) as
  declare aDif integer;
BEGIN

  select CURRENT_DATE-lastdate from rndatebuffer into :aDif;           -- detect date border
  if (aDif is null) then                                               -- init
  begin
    insert into rndatebuffer (lastdate) values(CURRENT_DATE);
    execute statement 'set generator gen_rn to 0';
  end

  If (aDif <> 0) then                                                  -- date border reached
  begin
    update rndatebuffer set lastdate=CURRENT_DATE;                     -- reset date buffer
    execute statement 'set generator gen_rn to 0';                     -- reset generator
  end

  for
    select                                                             -- build Rechnungsnummer 
      CAST(Extract(year FROM cast('NOW' as date))*10000 +
      Extract(month FROM cast('NOW' as date))*100 +
      Extract(day FROM cast('NOW' as date)) AS VARCHAR(8))||
      LPAD (gen_id(gen_rn,1), 6, '0') 
    from RDB$DATABASE into :prn
  do begin
    suspend;
  end
END
^

SET TERM ; ^

P.S.: der Aufruf wäre dann einfach

Code:

select * from GetRN;

[DCoderHH]

@jobo: Deine StoredProcedure GetRN aus Post #22 eignet sich auch für Multiuser-Zugriff? Was ist wenn 2 Clients die StoredProcedure gleichzeitig aufrufen? Ist das berücksichtigt?

[DCoderHH]

Zitat:

Zitat von rokli (Beitrag 1355438)

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

[mkinzler]

Zitat:

Zitat von DCoderHH (Beitrag 1355442)

@jobo: Deine StoredProcedure GetRN aus Post #22 eignet sich auch für Multiuser-Zugriff? Was ist wenn 2 Clients die StoredProcedure gleichzeitig aufrufen? Ist das berücksichtigt?

Ja, dafür sorgt die Semaphoren-Funktion gen_id()

[mkinzler]

Zitat:

Zitat von DCoderHH (Beitrag 1355443)

Zitat:

Zitat von rokli (Beitrag 1355438)

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

Man könnte ein select for update verwenden.

[Lemmy]

Zitat:

Zitat von mkinzler (Beitrag 1355445)

Zitat:

Zitat von DCoderHH (Beitrag 1355442)

@jobo: Deine StoredProcedure GetRN aus Post #22 eignet sich auch für Multiuser-Zugriff? Was ist wenn 2 Clients die StoredProcedure gleichzeitig aufrufen? Ist das berücksichtigt?

Ja, dafür sorgt die Semaphoren-Funktion gen_id()

-gelöscht-

Ich würde das anders umsetzen und wenn möglich einen "Buchungsschluss" laufen lassen, der den Zugriff auf die DB blockiert und der dann letztlich den Rechnungsnummerngenerator initialisiert. Aber ganz sicher nicht in der SP in der neue Rechnungsnummern generiert werden

[p80286]

Ich möchte nochmal anmerken, daß diese datumsabhängige Generierung nur für einen geografisch begrenzten Raum durchführbar ist. Egal ob LocalTime oder eine zentrale Zeit (Greenich) irgendwann ist eine Datumsgrenze erreicht, die mit einem "Datumsgefühl" kollidiert. Alleine in den USA gibt es eine Zeitdifferenz von 3 Stunden, Die Westküste hat einen Abstand von 9 Stunden zu Deutschland, wenn dort die erste Rechnung generiert wird, ist bei uns die letzte im System. Aber für solche Szenarien wurde die Datenbank nicht entworfen, und das Jahr 2000 war in weiter Zukunft.

Gruß
K-H

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1355446)

Zitat:

Zitat von DCoderHH (Beitrag 1355443)

Zitat:

Zitat von rokli (Beitrag 1355438)

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

Man könnte ein select for update verwenden.

Nach meinem Verständnis läuft das automatisch in einer Transaktion ab und würde keine Probleme bereiten. Dafür ist ja der Generator und Transaktionsicherheit da.

Notfalls mal ausprobieren und ein paar Consolen öffnen die in einer Loop Werte anfordern. Dazwischen manuel das Datum zurücksetzen. Dabei sollte nur eine einzige Sitzung einen Sequenzreset "erleben" und natürlich alle Sitzungen in Summe eindeutige Nummern liefern.

@Datumsgrenzen: Die sind natürlich international unterschiedlich. Das ist aber kein technisches Problem, sondern muss per Konvention vereinabrt werden, welche Datumsgrenze gewählt werden soll.

Ich selbst habe bei meinem Vorschlag eigentlich ein anderes Problem. Nämlich das Sequenzreset selbst. Ich bin mir nicht ganz sicher, wie das zu werten ist, aber es scheint als DML Befehl zu laufen und ich kenne es von anderen Systemen so, dass DML implizit commited. Das wäre aus meiner Sicht nicht wünschenswert.

[Ghostwalker]

Zitat:

Zitat von p80286 (Beitrag 1355448)

Ich möchte nochmal anmerken, daß diese datumsabhängige Generierung nur für einen geografisch begrenzten Raum durchführbar ist. Egal ob LocalTime oder eine zentrale Zeit (Greenich) irgendwann ist eine Datumsgrenze erreicht, die mit einem "Datumsgefühl" kollidiert. Alleine in den USA gibt es eine Zeitdifferenz von 3 Stunden, Die Westküste hat einen Abstand von 9 Stunden zu Deutschland, wenn dort die erste Rechnung generiert wird, ist bei uns die letzte im System. Aber für solche Szenarien wurde die Datenbank nicht entworfen, und das Jahr 2000 war in weiter Zukunft.

Gruß
K-H

Da hast du definitiv recht. Aber das Problem hast du generel mit Datumswerten, egal ob das nun in der
Rechnungsnummer oder sonstwo in der DB ist. Deshalb sollte man sich hier (Programmintern) auf eine Art einigen (i.d.R. GMT).