Inoffizielles deutsches Xbase-Forum

Hallo Marcus

das beschriebene Problem war in Deutschland als die "Datenträgerüberlassung" eingeführt wurde.
Die Deutschen Finanzbeamten haben die "Zufallsnummern" nach dem beschriebenen Muster dann aktzeptiert und so läuft es bis heute.
Es ist ja auch Datenschutz dass er Empfänger nicht nachvollziehen kann wieviele Rechnungen/Offerten/Lieferscheine usw. in einem Betrieb geschrieben werden.......

r- wie ich weiter oben geschrieben habe -

da hab ich wohl Einträge übersehen, kommt, weil man immer auf dem Letzten landet und nicht konsequent noch oben liest....

Werner_Bayern hat geschrieben: ↑Mo, 07. Jun 2021 12:40 Nein, alter Code mit dbf.

Hast recht ... hab mich auch durch das SQL blenden lassen;)
Aber Du kannst DBF mit ADS auch über SQL ansprechen (im lokalen Modus ohne Server, wenn die entsprechenden Lizenzbedingungen eingehalten werden).

Gibs auf Joachim, Du verkaufst uns hier keinen ADS für diese Funktionalität

Ein schönes Wochenende!

Hallo, Werner -


ich ziehe meinen Vorschlag mit Universal SQL zurück. Ich habe das aus Interesse mal probiert, aber Universal SQL scheitert noch an dem nested SELECT.

Servus Georg,

danke für die Info.

Hallo Werner,

gehe ich richtig in der Annahme, dass die meisten der ungültigen (stornierten) Datensätze dadurch entstehen, dass vor der eigentlichen Dateneingabe ein Datensatz durch DBAppend() angelegt wird und der User, aus welchen Gründen auch immer, die Dateneingabe abbricht?
Hier wäre es natürlich hilfreich, wenn ein Datensatz mit einer eindeutigen Beleg-Nummer erst dann erzeugt wird, wenn der User die Dateneingabe abgeschlossen hat und das Speichern des Datensatzes selbst anfordert. Sonstige unberechtigte Belege (z. B. abgelehnte oder falsch ausgestellte Rechnungen) sollten meiner Meinung nach niemals gelöscht, sondern nach der Erfassung entsprechend gekennzeichnet und dokumentiert werden.
Fazit: Das Append vor der Dateneingabe und das Löschen von existierenden Datensätzen sollte strikt vermieden werden. Dann erhält man automatisch lückenlose Nummernkreise.

Servus Dieter,

richtig, aber: Nur so ist sichergestellt, dass im Netzwerk (und auch lokal - Thread) keine Nummer doppelt vergeben wird.

Hallo Werner,

ich löse das n+1-Problem (ohne doppelte ID-Vergabe) mit Hilfe einer einer zentralen DBF, die ich nPeins.dbf genannt habe und die bei jedem Programmstart im Shared-Modus geöffnet wird. Jede DBF, die eine fortlaufende numerische ID verwaltet, hat hier einen eigenen Datensatz. Eine Applikation, die die nächst höhere ID für eine bestimmte DBF anfordert, muss zuerst den zugehörigen Datensatz in der nPeins.dbf sperren, um ein DBAppend() ausführen zu können. Das Positionieren auf den Record-Datensatz der nPeins.dbf geschieht sequentiell und ist somit unabhängig von einem Index. Die Sperrzeit ist in der Regel nur ein Bruchteil einer Sekunde, da nur gesperrt wird, wenn der User den Speicherbutton oder die Speicherfunktionstaste drückt.
Im jahrelangen Einsatz auf Terminalservern mit bis zu 40 gleichzeitigen Userzugriffen, wobei mehrere Personen gleichzeitig neue Daten erfassen, kam es bis jetzt zu keiner doppelten ID.
Bei älteren Programmen, die DBAppend() vor der Dateneingabe ausführen, habe ich die verworfenen IDs (vom User abgebrochene Datenerfassung) ebenfalls in einer zentralen DBF gespeichert und wieder zur Verfügung gestellt (wie von Georg hier vorgeschlagen). Das neue Verfahren ist meiner Meinung nach zu bevorzugen, da dadurch extrem kurze Sperrzeiten resultieren. Man muss aber sein gesamtes Datenhandling darauf aurichten. Die Eingabewerte liegen in den XbParts und werden erst am Ende der Erfassung gespeichert und bekommen dann erst die automatisch erzeugte ID.