Im numerischen Index freie Werte finden
Moderator: Moderatoren
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Im numerischen Index freie Werte finden
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.......
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.......
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Marcus Herz
- 1000 working lines a day
- Beiträge: 861
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 39 Mal
- Danksagung erhalten: 197 Mal
- Kontaktdaten:
Re: Im numerischen Index freie Werte finden
da hab ich wohl Einträge übersehen, kommt, weil man immer auf dem Letzten landet und nicht konsequent noch oben liest....r- wie ich weiter oben geschrieben habe -
Gruß Marcus
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
- nightcrawler
- 1000 working lines a day
- Beiträge: 653
- Registriert: Di, 24. Apr 2012 16:33
- Wohnort: 72184 Weitingen
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 96 Mal
- Kontaktdaten:
Re: Im numerischen Index freie Werte finden
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).
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2127
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Im numerischen Index freie Werte finden
Gibs auf Joachim, Du verkaufst uns hier keinen ADS für diese Funktionalität
Ein schönes Wochenende!
Ein schönes Wochenende!
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2830
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 97 Mal
- Danksagung erhalten: 13 Mal
Re: Im numerischen Index freie Werte finden
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.
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.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2127
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Im numerischen Index freie Werte finden
Servus Georg,
danke für die Info.
danke für die Info.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Rekursionen-Architekt
- Beiträge: 237
- Registriert: Do, 14. Aug 2008 14:59
- Wohnort: Straelen
- Hat sich bedankt: 2 Mal
- Danksagung erhalten: 3 Mal
Re: Im numerischen Index freie Werte finden
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.
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.
Viele Grüße
Dieter
Was man nicht versteht, besitzt man nicht.
Dieter
Was man nicht versteht, besitzt man nicht.
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2127
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Im numerischen Index freie Werte finden
Servus Dieter,
richtig, aber: Nur so ist sichergestellt, dass im Netzwerk (und auch lokal - Thread) keine Nummer doppelt vergeben wird.
richtig, aber: Nur so ist sichergestellt, dass im Netzwerk (und auch lokal - Thread) keine Nummer doppelt vergeben wird.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
-
- Rekursionen-Architekt
- Beiträge: 237
- Registriert: Do, 14. Aug 2008 14:59
- Wohnort: Straelen
- Hat sich bedankt: 2 Mal
- Danksagung erhalten: 3 Mal
Re: Im numerischen Index freie Werte finden
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.
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.
Viele Grüße
Dieter
Was man nicht versteht, besitzt man nicht.
Dieter
Was man nicht versteht, besitzt man nicht.