Doppelte Nummervergabe.

andreas · Beitrag von **andreas** » Fr, 13. Jul 2007 10:02

Hallo,

ich habe ein Problem, dass trotz aller meiner Versuche immer wieder auftritt.
Ich habe eine DBF-Datei im FOXCDX-Format, die für die vergabe eindeutiger Nummern verwendet wird. Die Datei liegt auf dem MS Windows 2003 Server mit abgeschalteten Caching. Die Clients haben Win98, Win2000 und WinXP.
Bei der Nummernvergabe wird die Datei Exclusive geöffnet. Trotzdem kommt es ab und zu, dass doppelte Nummern auftauchen.
Früher habe ich nur den Datensatz gesperrt, wo das Problem aber öfters kam. Mit dem Exclusiven Öffnen sollte das überhaupt nicht mehr vorkommen, passiert aber trotzdem.
Was kann das überhaupt sein. Ich habe keine Ideen mehr.

Markus Walter · Beitrag von **Markus Walter** » Fr, 13. Jul 2007 10:36

Hallo Andreas,

ich kenne das Problem nicht. In meiner Applikation gibt es praktisch das gleiche System und zusätzlich ein System ohne exclusives Öffnen.

Meine Vorgehensweise A:
Alle Instanzen haben die Datei geöffnet, Satzsperre, Wert lesen, erhöhen, reinschreiben, Sperre aufheben, Commit

Meine Vorgehensweise B:
Datei wird exlusiv geöffnet, Wert lesen, erhöhen, reinschreiben, Datei schliessen.

Doppelte IDs hatte ich bei beiden Systemen noch nicht. Allerdings gibt es in meiner Applikation auch keinen wirklich starken "Load" bei der Sache (es geht z. B. um Auftragsnummern), d. h. es werden pro Tag vielleicht 100-200 IDs erzeugt...

Ich verwende FOXCDX und nehme an allen Anlagen die "einschlägig bekannten" Registry-Einstellungen bzgl. Opportunistic Locking vor).
Anlagengrößen: 1-Platz bis 20 Arbeitsplätze, alles Win2000, Win2003 oder XP, KEIN Win9x

andreas · Beitrag von **andreas** » Fr, 13. Jul 2007 10:45

Hallo Markus,

deine Vorgehensweise A hatte ich am Anfang. Als das Problem aufgetreten ist, hatte ich auf die Vorgehensweise B umgestellt. Jetzt kommt es sehr selten aber trotzdem vor, dass die doppelten Nummern auftauchen.
Ich vermute, dass es von Win98 kommen könnte und dass es irgendwie mit den Dateisperren an dieser Stelle nicht richtig funktioniert. Ich kann aber Win98 nicht abschalten, da es kleine Clients ohne Festplatte sind und da immer die Fertigungsdaten erfasst werden. Es sind auch nur ca. 6-8 Plätze.

Beitrag von **Tom** » Fr, 13. Jul 2007 11:39

Hallo, Andreas.

Ich kenne das Problem auch, und zwar unter allen möglichen Topologien. Deshalb gibt es bei uns seit Jahren schon gesonderte Tabellen für die Nummernverwaltung, die jeweils nur einen Datensatz haben. Diese Tabellen werden im Bedarfsfall geöffnet, der Datensatz wird gesperrt, die Nummer wird inkrementiert und die Tabelle wird wieder geschlossen. Seitdem ist das Problem nicht mehr aufgetreten. Hilfsweise geht das auch mit XPF-, INI- oder XML-Dateien, wobei man sich hier noch gesonderte Sperrmechanismen ausdenken muß.

andreas · Beitrag von **andreas** » Fr, 13. Jul 2007 12:16

Hallo Tom,

genau so habe ich es auch gemacht. Ich habe eine Extra-Datei mit einem Datensatz. Diese wird erst dann geöffnet, wenn ich die Nummer brauche. Die Satzsperre habe ich damals durch die Dateisperre (exclusives Öffnen) abgelöst. Das Problem ist immer noch da.
Hier ist mein Code:

Code: Alles auswählen

FUNCTION GetNummer(cAuswahl)
	local nAuftragNeu:=0, cAuftragNeu:="", db:=select(), nJahr:=YEAR(date())
	/*
	Local aStruckt:={;
		{"Jahr","N",2,0},;
		{"Auftrag","N",7,0},;
		{"LaufKarte","N",7,0},;
		{"Behaelter","N",9,0},;
		{"Liefersch","N",8,0};
		}
	 */

	Default cAuswahl to "AUFTRAG"

	/*
	IF ! file("Nummern.dbf")
		dbcreate("Nummern", aStruckt, "FOXCDX")
	ENDIF
	*/
	IF len(alltrim(str(nJahr)))==4

		nJahr:= val(substr(alltrim(str(nJahr)),3))
	ENDIF



	*use Nummern alias Nummern via "FOXCDX" new exclusive

	do while ! DBNummerOpen()
		sleep(5)
	enddo

	*IF ! neterr()

	IF lastrec()==0
		dbappend()
		replace nummern->jahr with nJahr
		*dbrunlock()

	ENDIF

	go 1
	*do while ! dbrlock()
	*enddo

	IF nJahr > nummern->jahr
		**zurücksetzen der Werte, wenn das Jahr sich gewechselt hat
		replace nummern->jahr with nJahr
		replace nummern->auftrag with 0
		replace nummern->LaufKarte with 0
		replace nummern->Behaelter with 0
		replace nummern->Liefersch with 0
	ENDIF


	IF upper(cAuswahl)=="AUFTRAG"

		nAuftragNeu:=nummern->auftrag+1
		replace nummern->auftrag with nAuftragNeu
		cAuftragNeu:="A"+strzero(nJahr,2)+strzero(nAuftragNeu,7)

	elseIF upper(cAuswahl)=="LAUFKARTE"

		nAuftragNeu:=nummern->LaufKarte+1
		replace nummern->LaufKarte with nAuftragNeu
		cAuftragNeu:="LK"+strzero(nJahr,2)+strzero(nAuftragNeu,7)

	elseIF upper(cAuswahl)=="BEHAELTER"

		nAuftragNeu:=nummern->Behaelter+1
		replace nummern->Behaelter with nAuftragNeu
		cAuftragNeu:="B"+strzero(nJahr,2)+strzero(nAuftragNeu,9)

	elseIF upper(cAuswahl)=="LIEFERSCHEIN"

		nAuftragNeu:=nummern->Liefersch+1
		replace nummern->Liefersch with nAuftragNeu
		cAuftragNeu:="HL"+strzero(nJahr,2)+strzero(nAuftragNeu,8)

	elseIF upper(cAuswahl)=="RLIEFERSCHEIN"

		nAuftragNeu:=nummern->RLief+1
		replace nummern->RLief with nAuftragNeu
		cAuftragNeu:="RL"+strzero(nJahr,2)+strzero(nAuftragNeu,8)

	ENDIF
	*dbrunlock()
	nummern->(dbcommit())

	close Nummern


	*ENDIF

	IF db>0
		select (db)
	ENDIF

RETURN cAuftragNeu


FUNCTION DBNummerOpen()
	local lOk := .f.
	Local aStruckt:={;
		{"Jahr","N",2,0},;
		{"Auftrag","N",7,0},;
		{"LaufKarte","N",7,0},;
		{"Behaelter","N",9,0},;
		{"Liefersch","N",8,0},;
		{"RLief","N",8,0};
		}

	IF ! file("Nummern.dbf")
		dbcreate("Nummern", aStruckt, "FOXCDX")
	ENDIF

	bSaveError := ErrorBlock()
	ErrorBlock( {|e| Break(e)} )

	BEGIN SEQUENCE

		use Nummern alias Nummern via "FOXCDX" new exclusive
		IF ! neterr()
			lOk := .t.
		else
			lOk := .f.
		endif

	RECOVER
		ErrorBlock( bSaveError )
		lOk := .f.
	END SEQUENCE
	ErrorBlock( bSaveError )

RETURN lOk

Wie ich es sehe, darf mit diesem Code keine doppelte Nummer auftauchen.

Beitrag von **Bertram Hansen** » Fr, 13. Jul 2007 12:48

Hallo Andreas,

ich verwende folgende Methode um die Belegnummer eindeutig zu erstellen:
- Datensatz suchen.
- Datensatz sperren. Die anderen User stehen in der Zwischenzeit in einer Warteschleife und warten solange bis der erste User den Datensatz wieder freigibt.
- alias->(dbskip(0))
- über eine Varaible die Belegnummer erhöhen.
- die neue Belegnummer in die Tabelle schreiben.
- dbcommitall()
- alias->dbunlock()

Damit haben wir seit Jahren keine doppelten Belegnummern mehr. Den alias->(dbskip(0)) haben wir nachträglich eingefügt, ohne den Zusatz hatten wir auch Probleme gehabt. Vielleicht hilft Dir das weiter.

Beitrag von **AUGE_OHR** » Fr, 13. Jul 2007 12:52

hi,

andreas hat geschrieben:
Code: Alles auswählen
   use Nummern alias Nummern via "FOXCDX" new exclusive

hm ... wird bei NEW nicht jedesmals eine neuer SELECT() Bereich
geöffnet ? Ich hatte es schon (unter Xbase++) das verschiedene
Workstationen EXCLUSIVE die selbe DBF in verschiedenen SELECT()
geöffnet hatten ... nimm mal das NEW raus.

was mir bei deiner Routine fehlt ist die Prüfung der Nummer sobald
du die vergeben hast ob die nicht schon exitiert. Ich prüfe das auch
noch bevor ich die "neuen" Datensätze APPENDe ob nicht in der Zwischen-
zeit jemand anderes die Nummer verwendet (warum/wieso auch immer)

grundsätzlich hab ich deine W98 Workstationen in Verdacht den ähnliche
Phänomäne hab ich auch mit dem W2003 Server und den W98 Stationen
gehabt welche ich nun auf W2K umgestellt habe.

gruss by OHR
Jimmy

Rolf Ramacher · Beitrag von **Rolf Ramacher** » Fr, 13. Jul 2007 15:41

Hallo Andreas,

als der Hinweis von Jimmy den NEW rauszunehmen würde ich nicht machen, weil du sonst in den Select-Bereich von einer anderen Datenbank kommst.

Aber sonst ist die vorgehensweise schon richtig. DBF öffnen - sperren -
Nummern erhöhen - schreiben - closen.

Aber das Sperren von Win98-Rechnern hatte ich auch schon mal. Aber die Lösung weiß ich nicht mehr. Was für ein Netzwerk wird denn eingesetzt. Vielleicht hat es ja auch damit zu tun, daß das sperren nicht sauber funktioniert - karten, treiber ect.

andreas · Beitrag von **andreas** » Fr, 13. Jul 2007 15:46

Rolf Ramacher hat geschrieben:Hallo Andreas,

als der Hinweis von Jimmy den NEW rauszunehmen würde ich nicht machen, weil du sonst in den Select-Bereich von einer anderen Datenbank kommst.

Aber sonst ist die vorgehensweise schon richtig. DBF öffnen - sperren -
Nummern erhöhen - schreiben - closen.

Aber das Sperren von Win98-Rechnern hatte ich auch schon mal. Aber die Lösung weiß ich nicht mehr. Was für ein Netzwerk wird denn eingesetzt. Vielleicht hat es ja auch damit zu tun, daß das sperren nicht sauber funktioniert - karten, treiber ect.

Hallo Rolf,

mit dem Rausnehmen von NEW kann ich dir nur zustimmen - das bring nur Probleme und keine Lösung.
Bei dem Netzwerk ist es wie bei allen: RJ45 Verkabelung, Windows-Domäne mit den Clients, die sich in der Domäne anmelden.

Beitrag von **Tom** » Fr, 13. Jul 2007 15:51

Hallo, Andreas.

Ich würde Dir empfehlen, Deine Funktion DBNummerOpen() dahingehend zu ändern, daß Sie die Tabelle öffnet, die Nummern inkrementiert, die Datei wieder schließt und ein Array mit den (nächsten) Nummern retourniert.

Code: Alles auswählen

FUNCTION DbNummernOpen()
LOCAL aNummern := {}
* ... öffnen, sperren, Nummern inkrementieren
aAdd(aNummern,Db->Auftrag)
aAdd(aNummern,Db->Laufkarte) // usw.
* ...
DbCloseArea()
* reselektieren
RETURN aNummern

Und in der eigentlichen Vergaberoutine:

Code: Alles auswählen

LOCAL aNummern := DbNummernOpen()
* ...
Auf->Auftrag := aNummern[1] // usw.

Rolf Ramacher · Beitrag von **Rolf Ramacher** » Fr, 13. Jul 2007 15:53

Hallo Andreas,

ist es ein HUB oder eine Ringverteilung - also peer to peer.

Läßt sich denn der Fehler bei einer bestimmten vorgehensweise reproduzieren ? Oder treten beim kopieren von Dateien übers Netzwerk
Fehler auf ? Läßt sich feststellen, ob dies von einem bestimmten Client
abhängt ??

Ich denke mal dieses zu prüfen wird schwierig sein. Aber in punkto Netzwerkkarten, Verkabelung, Treibern ect. habe ich einiges erlebt was
passieren kann.

Beitrag von **AUGE_OHR** » Fr, 13. Jul 2007 22:13

hi,

Rolf Ramacher hat geschrieben: als der Hinweis von Jimmy den NEW rauszunehmen würde ich nicht machen, weil du sonst in den Select-Bereich von einer anderen Datenbank kommst.

hätte mich wohl genauer ausdrücken sollen was ich damit meine.

Ein NEW öffnet ja die DBF im nächsten möglichen SELECT(). Ich
verwende aber grundsächlich "festes" SELECT() zusammen mit
dem ALIAS(). So ist "SELECT 28" immer KDNUMMER und kann
nicht "nochmal" in der selben WorkArea vorkommen, auch nicht
mit andem ALIAS().

Dazu verwende ich meine NET_USE() wo ich zunächst den SELECT()
einstelle, dann die DBF öffne und auch die Index Datei(n) alles in
dem selben Modul. Das hat mir bei NTX Index Datein auch geholfen
immer alle dazugehörigen NTX Datein in der selben Reihenfolge zu
öffnen und keine zu "vergessen"

Die Vorgehensweise würde ich grundsätzlich jedem raten und nicht
"irgendwo" im Source verteilt die DBF/Index öffnen. Will man nun
z.b. von NTX nach CDX "umstellen" so muss man nur an der NET_USE()
die Anpassung vornehmen (DBESYS setzt ich vorraus ...)

selbstverständlich muss man sich dann "manuelle" und die SELECT()
Bereiche kümmern, aber das Wissen darum hab ich vorrausgesetzt
den wir sind ja keine Newbie´s mehr.

gruss by OHR
Jimmy

andreas · Beitrag von **andreas** » So, 15. Jul 2007 9:07

Hallo jimmy,

ich denke, dass dein Vorschlag mit dem Rausnehmen von NEW in meinem Fall nichts bringen wird, da ich die Datenbank Exclusive öffne, was nach XBase weiteres Öffnen der Datenbank (zumindest mit Schreibrechten) nicht mehr möglich macht. Das funktioniert ja auch, aber wohl nicht immer in zusammenarbeit mit Win98.

Beitrag von **AUGE_OHR** » So, 15. Jul 2007 14:14

hi,

andreas hat geschrieben:ich denke, dass dein Vorschlag mit dem Rausnehmen von NEW in meinem Fall nichts bringen wird, da ich die Datenbank Exclusive öffne, was nach XBase weiteres Öffnen der Datenbank (zumindest mit Schreibrechten) nicht mehr möglich macht. Das funktioniert ja auch, aber wohl nicht immer in zusammenarbeit mit Win98.

aber schaden würde es auch nicht und evtl. findest du dann denFehler.
Im Alaska Forum hatte jemand unter dem Title "File handle limit in XP"
gerade ein ähnliches Problem mit exlusiven öffnen ...

gruss by OHR
Jimmy

Beitrag von **brandelh** » Mo, 16. Jul 2007 0:28

Hi,

ich kann mich ja täuschen, aber ich sehe keine Abfrage nach ! NetErr() !
Diese muss auch bei exclusive immer abgefragt werden, da alle möglichen Fehler dazu führen können. Wird der Fehler ignoriert, müsste das zwar später bemerkt werden, aber besser gleich blocken.

andreas · Beitrag von **andreas** » Mo, 16. Jul 2007 8:00

brandelh hat geschrieben:Hi,

ich kann mich ja täuschen, aber ich sehe keine Abfrage nach ! NetErr() !
Diese muss auch bei exclusive immer abgefragt werden, da alle möglichen Fehler dazu führen können. Wird der Fehler ignoriert, müsste das zwar später bemerkt werden, aber besser gleich blocken.

Hallo Hubert,

wenn du die Funktion DBNummerOpen ansiehst, findest du da folgenden Block:

Code: Alles auswählen

...
   BEGIN SEQUENCE

      use Nummern alias Nummern via "FOXCDX" new exclusive
      IF ! neterr()
         lOk := .t.
      else
         lOk := .f.
      endif

   RECOVER 
...

Ich habe schon alle Möglichkeiten eingeschlossen, die ich kenne.

Beitrag von **AUGE_OHR** » Mo, 16. Jul 2007 14:41

hi,

andreas hat geschrieben: wenn du die Funktion DBNummerOpen ansiehst, findest du da

ja aber theoretisch könnte er in der Schleife :

Code: Alles auswählen

   do while ! DBNummerOpen() 
      sleep(5) 
   enddo

hängen bleiben.

andreas hat geschrieben: Das funktioniert ja auch, aber wohl nicht immer in zusammenarbeit mit Win98.

hm ... Win98se TCP/IP ? ... VREDIR.VXD ... da war doch was ...

nur TCP/IP oder noch ein Protokoll ? wenn mehrere welches "first" ?

verwendes du "mapped drive letter" oder UNC Bezeichnung ?

waren die vielleicht vorher an einen Novell Server angeschlossen und
haben den NW-Client verwendet ?

Power Management oder Screen Saver ?

zu Xbase++
wird GetNummer() per Thread aufgerufen ?
wird GetNummer() direkt aus dem Menue oder "tiefer" im Programm ?

weiterer Vorschlag : die vergebene Nummer nochmals gegenprüfen ob
z.bb eine solche Auftragsnummer schonj im Bestand vorhanden ist.

gruss by OHR
Jimmy

Beitrag von **brandelh** » Mo, 16. Jul 2007 19:24

andreas hat geschrieben:
brandelh hat geschrieben:Hi,

ich kann mich ja täuschen...
Hallo Hubert,

wenn du die Funktion DBNummerOpen ansiehst, findest du da folgenden Block:
Code: Alles auswählen
...
   BEGIN SEQUENCE

      use Nummern alias Nummern via "FOXCDX" new exclusive
      IF ! neterr()
         lOk := .t.
      else
         lOk := .f.
      endif

   RECOVER 
...
Ich habe schon alle Möglichkeiten eingeschlossen, die ich kenne.

War wohl doch schon zu spät

andreas · Beitrag von **andreas** » Di, 17. Jul 2007 8:07

Hallo Jimmy,

AUGE_OHR hat geschrieben:
andreas hat geschrieben: wenn du die Funktion DBNummerOpen ansiehst, findest du da
ja aber theoretisch könnte er in der Schleife :
Code: Alles auswählen
   do while ! DBNummerOpen() 
      sleep(5) 
   enddo 
hängen bleiben.

Das ist auch so gewollt. Das Programm darf nicht weiter kommen, so lange die Nummer nicht ermittelt wurde.

AUGE_OHR hat geschrieben: nur TCP/IP oder noch ein Protokoll ? wenn mehrere welches "first" ?

nur TCP/IP

AUGE_OHR hat geschrieben: verwendes du "mapped drive letter" oder UNC Bezeichnung ?

mapped drive letter

AUGE_OHR hat geschrieben: waren die vielleicht vorher an einen Novell Server angeschlossen und
haben den NW-Client verwendet ?

Es war nie ein Novell-Client drauf.

AUGE_OHR hat geschrieben: Power Management oder Screen Saver ?

Kann ich jetzt nicht sagen, aber bestimmt keiner während der Eingabe.

AUGE_OHR hat geschrieben: zu Xbase++
wird GetNummer() per Thread aufgerufen ?
wird GetNummer() direkt aus dem Menue oder "tiefer" im Programm ?

Die Funktion wird aus der Speichern-Funktion im gleichen Thread aufgerufen.

AUGE_OHR hat geschrieben: weiterer Vorschlag : die vergebene Nummer nochmals gegenprüfen ob
z.bb eine solche Auftragsnummer schonj im Bestand vorhanden ist.

Anscheinend bleibt mir nichts über, als deinem Vorschlag nachzugehen und die zus. Prüfung einzubauen.

andreas · Beitrag von **andreas** » Di, 17. Jul 2007 13:39

Hallo Jimmy,

ich wollte gerade die Speichern-Funktion um die Überprüfung der Nummer erweitern und habe festgestellt, dass ich das schon mal gemacht habe:

Code: Alles auswählen

**neue Behälternummer ermitteln und dabei prüfen, ob die schon vorhanden ist.
			select Behaelter
			set order to tag "behaeltnr"
			do while .t.
				cBehaelterNr := GetNummer("BEHAELTER")
				sleep(2)
				select Behaelter
				IF ! dbseek( cBehaelterNr )
					exit
				ENDIF
			enddo

D.h. dass das Problem wirklich irgendwo mit dem gleichzeitigem Zugreifen von mehreren PCs zusammenhängt.

Beitrag von **Martin Altmann** » Di, 17. Jul 2007 13:46

Hallo Andreas,
wie Bertram bereits schrieb:
Nicht nur Commit() nach dem Ersetzen des Feldes, sondern auch ein DbSkip(0), um den Buffer zu refreshen...

Viele Grüße,
Martin

Beitrag von **Bertram Hansen** » Mi, 18. Jul 2007 13:08

Hallo Martin,

es ist ein schöööönes Gefühl auch mal etwas zur Problemlösung beigetragen zu haben. Bisher habe ich von diesem hervoragendem Forum nur profitiert.

Beitrag von **Martin Altmann** » Mi, 18. Jul 2007 13:14

Hallo Bertram,
ob es Andreas wirklich geholfen hat, weiß ich ja noch nicht!
Aber ich auch mal davon aus, dass es helfen wird

Viele Grüße,
Martin

andreas · Beitrag von **andreas** » Do, 19. Jul 2007 16:48

Ich habe jetzt DBskip(0) so oft gesetzt, wie ich konnte. Jetzt kann ich nur das Programm beim Kunden einspielen und abwarten, was aber länger dauern kann.

Beitrag von **brandelh** » Do, 19. Jul 2007 23:05

Hi,

ich habe schon zu Clipper Zeiten die Erfahrung gemacht, dass man commit vergessen kann. skip 0 bzw. dbskip(0) ist wesentlich besser. Danach hatte ich keine Probleme mehr - solange die Netzhardware fehlerfrei funktionierte.