mir fällt da kein Lösungsweg ein, der auf der Schiene besser wäre - vielleicht kommt ja ein Vorschlag, ich denke, da gibt es vielleicht die eine oder andere Möglichkeit.
Wenn die Lücken entstehen, da Datensätze gelöscht werden, würde ich (so habe ich das in einer Applikation gelöst) eine Schlüsseldatei führen. Wird ein Satz gelöscht, wird dessen ID in die Schlüsseldatei geschrieben. Wird ein neuer Satz geschrieben, wird erst in der Schlüsseldatei nachgesehen, ob ein freier Platz vorhanden ist, und die ID verwendet und aus der Schlüsseldatei gelöscht, ansonsten wird der neue Satz mit dem höchsten Schlüsselwert + 1 angelegt.
Ich würde das auch gesondert verwalten (und ggf. durch Servicefunktionen überprüfen, etwa im Rahmen der Datenwartung), denn ein solches System hat zur Folge, dass man im Zweifelsfall jedes Mal ergebnislos sucht, weil es tatsächlich keine freien Plätze gibt.
Es sind zwei Informationen von Interesse: a) Die höchste vergebene Nummer - das ist leicht. Und b) die höchste recycelte. Da es einen Prozess geben muss, der Nummern für das Recycling freigibt, würde ich dort ansetzen, also diese Nummern wegspeichern (und im Fall des Recyclings von dort entfernen).
danke, interessanter Ansatz. Da aber an versch. Stellen gelöscht werden kann - manuell oder durch die Anwendung - ist mir das zu triggy / aufwändig, bzw. kann Folgefehler erzeugen, die ich mir nicht leisten kann und will.
Dann muss der Kunde die max. 0,5 Sekunden Wartezeit in Kauf nehmen.
genau so ist es. Siehe meine Antwort an Georg: Aufwand und Risiko sind mir da zu hoch.
Da mach ich lieber eine neue Systemeinstellung, in der der Kunde die Anzahl angegeben kann, die maximal rückwärts durchsucht wird.
Meine Hoffnung war, dass es evtl. eine geniale Lösung über dbseek mit lLast oder über den Indexausdruck gibt...
Werner,
Warum auch immer keine Lücken sein sollen...
Du kannst z.B. nach dem Programmstart eine Routine laufen lassen, die im Hintergrund die (ev. nur letzten 20) freien Nummern sucht und festhält.
Bei der nächsten Verwendung holst aus diesem Antwort-Array das erste Element, checkst und verwendest dieses. Anschliessend wird es dort gelöschs.
Hallo Werner,
und wenn Du eine Tabelle mit den freien führst und mit Triggern automatisch befüllst? Dann geht es auch im Multiuser.
Bei ADS ungefähr so:
create trigger trig_del on mytable after delete
begin
insert into num_cache(nummer) select nummer from __old;
end;
create trigger trig_ins on mytable after insert
begin
delete from num_cache where nummer = select nummer from __new;
end;
du könntest auch die fehlenden Nummern in Form von gelöschten Datensätzen in der Datenbank behalten.
Wenn die Datenbank die gelöschten Sätze noch enthält (also nicht gepackt wurde), könntest du das DELETED-Kennzeichen in einen Index einbauen und über diesen Index schnell den ersten (oder nächsten) gelöschten Satz suchen.
Allerdings musst du trotzdem prüfen, ob es zu dem gelöschten Satz nicht außerdem noch einen ungelöschten Satz mit gleicher Nummer gibt (und ggf. den nächsten gelöschten Satz suchen).
Außerdem musst du beim Packen aufpassen, denn nach dem Packen müsstest du dann eine Routine laufen lassen, die dir zu jeder fehlenden Nummer wieder einen gelöschten Satz anlegt. Und dieser "erweiterte" Packvorgang muss auch regelmäßig stattfinden, damit du nicht immer wieder dieselben gelöschten Datensätze durchsuchst, deren Nummern inzwischen schon wiederverwendet wurden.
Die Frage habe ich mir auch gestellt, Hubert. Gelegentlich hört man diese Anforderung von Kunden, die sich die Wiederverwendung von Beleg- und Rechnungsnummern wünschen, weil das einfacher ist, als dem FA ein Storno zu erklären und es zu belegen. Zulässig wäre es in diesem Fall allerdings nicht.
Wenn es um Nummern geht, die für interne Referenzen verwendet werden, sei immer wieder darauf verwiesen, dass die Verwendung von (U)UIDs viel komfortabler und sogar interoperabel ist. Wir verwenden echte, fortlaufende Nummern nur noch dort, wo es tatsächlich nötig ist, wo also die Nummern nach außen sichtbar sind und ggf. sogar von Dritten verwendet werden, also Kunden- und Rechnungsnummern und ähnliches. Aber auch die werden nicht mehr für Verknüpfungen verwendet.
Tom hat geschrieben: ↑Do, 10. Jun 2021 9:40
Gelegentlich hört man diese Anforderung von Kunden, die sich die Wiederverwendung von Beleg- und Rechnungsnummern wünschen, weil das einfacher ist, als dem FA ein Storno zu erklären und es zu belegen. Zulässig wäre es in diesem Fall allerdings nicht.
Ich könnte mir vorstellen, dass Rechnungsnummern reserviert wurden in der Absicht, Rechnungen zu schreiben, die dann tatsächlich nicht geschrieben wurden. Dann gibt es keine Buchung und kein Storno, und man muss die Reservierung wieder entfernen.
Ich habe gerade mal ein bisschen die Rechtslage studiert. Die Finanzämter wünschen sich fortlaufende, lückenlose Rechnungsnummern, aber mehrere Finanz- und Verwaltungsgerichtsentscheidungen haben klargestellt, dass es genügt, einmalige Rechnungsnummern zu vergeben, ganz egal, ob das lückenlos oder mit wilden Sprüngen zwischen den Zahlen geschieht (die den Kunden suggerieren sollen, man würde wie der Teufel Rechnungen schreiben) - oder wie die Nomenklatur überhaupt ist (Buchstaben, Sonderzeichen usw.).
Eine Rechnungsnummer, die nach draußen gegangen ist, darf man nicht wiederverwenden. Eine, mit der das nicht geschehen ist, kann auch verwendet werden, obwohl es bereits eine höhere Folgenummer gibt.
Aus dem täglichen Erleben bei Kunden: Wenn mit fortlaufenden und scheinbar konsistenten Nummernkreisen gearbeitet wird und es kommt zur Prüfung, wird energisch erfragt, was mit den vermeintlich fehlenden Nummern geschehen ist. Die Prüfer vermuten sofort Betrug.
Tom hat geschrieben: ↑Do, 10. Jun 2021 11:19
Eine Rechnungsnummer, die nach draußen gegangen ist, darf man nicht wiederverwenden. Eine, mit der das nicht geschehen ist, kann auch verwendet werden, obwohl es bereits eine höhere Folgenummer gibt.
Aus dem täglichen Erleben bei Kunden: Wenn mit fortlaufenden und scheinbar konsistenten Nummernkreisen gearbeitet wird und es kommt zur Prüfung, wird energisch erfragt, was mit den vermeintlich fehlenden Nummern geschehen ist. Die Prüfer vermuten sofort Betrug.
Darum geht's bei diesem Kunden. Lücken entstehen, das ist normal, Martin hats beschrieben.
Letzten Satz hören wir auch immer wieder mal, den können wir aber mit Martins Aussage immer zu 100% entkräften - da gabs noch nie ein Problem. Klar, der Prüfer schnauft dann, aber das ist ja gut für ihn
nightcrawler hat geschrieben: ↑Do, 10. Jun 2021 8:53
Hallo Werner,
und wenn Du eine Tabelle mit den freien führst und mit Triggern automatisch befüllst? Dann geht es auch im Multiuser.
Servus Joachim,
wie schon geschrieben, in diesem Fall geht's um DBF, kein SQL.
Tom hat geschrieben: ↑Do, 10. Jun 2021 11:19
Aus dem täglichen Erleben bei Kunden: Wenn mit fortlaufenden und scheinbar konsistenten Nummernkreisen gearbeitet wird und es kommt zur Prüfung, wird energisch erfragt, was mit den vermeintlich fehlenden Nummern geschehen ist. Die Prüfer vermuten sofort Betrug.
Deshalb stellen wir die Rechnungsnummer schon lange aus dem Datum und einer pro Tag einmaligen Zufallszahl zusammen.
zB. 210610452 eine Rechnungsnummer von heute.
So sind über die Nummern ausser dem Datum keine Rückschlüsse auf irgendwas mehr möglich.
Auf der Rechnung muss eine fortlaufende Nummer vermerkt sein. Als Rechnungsnummern sind nicht nur Ziffern, sondern auch Kombinationen mit Buchstaben zulässig, z. B. B-007-KR-2004. Solange die Rechnungsnummern eindeutig sind, dürfen auch mehrere Nummernkreise, z. B. nach Inland, Ausland, Filialen, gebildet werden.
Damit ist grundsätzlich eine durchgehende lückenlose Nummerierung gefordert.
Das sind die deutschen Regeln
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Das ist "gefordert" bzw. "gewünscht", Marcus, aber - wie ich weiter oben geschrieben habe - Gerichte haben entschieden, dass die Finanzämter damit nicht durchkommen. Rechnungsnummern können tatsächlich beliebige Identifikatoren sein, und die einzige rechtlich haltbare Vorschrift ist die, dass keine Doppelvergabe erfolgen darf. Auch die Reihenfolge ist im Prinzip frei wählbar.
Was der einzelne Finanzbeamte Wirtschaftsprüfer dann erklärt, ist leider wieder eine andere Sache.