HILFE: Schreiben von Daten in die DBF über Netzwerk !

[xbaseklaus]

Hallo,

bräuchte dringend einen Denkanstoß warum folgendes im Netzwerk nicht funktioniert !

Netzwerkanwendung: Das Programm läuft auf 2 Windows 7 PCs . Ein Windows PC ist der Server !

Bei schreiben von gefilterten Daten (DBappend) vom Arbeitsplatzrechner in eine DBF auf den Server werden nicht alle Daten übernommen, nur etwa 50% der mit APPEND angefügten Daten.

Es gibt keinen Fehler?

Starte ich das Programm 2mal auf dem gleichen PC (Server) und lasse dann die Append - Anweisung abarbeiten werden alle Daten übernommen !!!

Warum funktioniert das nur lokal und nicht im Netzwerk. Und unter Clipper traten diese Probleme nie auf !

Kann mir bitte jemand helfen.

mfg Klaus

[AUGE_OHR]

Netzwerkanwendung: Das Programm läuft auf 2 Windows 7 PCs . Ein Windows PC ist der Server !

also P2P ...

Bei schreiben von gefilterten Daten (DBappend) vom Arbeitsplatzrechner in eine DBF auf den Server werden nicht alle Daten übernommen, nur etwa 50% der mit APPEND angefügten Daten.

Es gibt keinen Fehler ?

schon mal was über "opportunistic lock" (oplock) gehört ...

Starte ich das Programm 2mal auf dem gleichen PC (Server) und lasse dann die Append - Anweisung abarbeiten werden alle Daten übernommen !!!

Warum funktioniert das nur lokal und nicht im Netzwerk. Und unter Clipper traten diese Probleme nie auf !

das ist nicht richtig denn das "Problem" ist das selbe für ALLE File basierenden System

[brandelh]

ich tippe mal auf die 3 Cacheeinstellungen die Windows 7 beschert hat.

SMP2 Patch von Alaska installieren !

http://www.xbaseforum.de/viewtopic.php?f=21&t=8239

PS:
mit Windows 2000 wäre das nie passiert.
mit Windows XP eventuell auch nicht

[AUGE_OHR]

ich tippe mal auf die 3 Cacheeinstellungen die Windows 7 beschert hat.

SMP2 Patch von Alaska installieren !

gemeint ist der SMB Patch welche die 3 Einstellungen "abschaltet" http://technet.microsoft.com/en-us/libr ... 10%29.aspx

Code: Alles auswählen

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters
DirectoryCacheLifetime
FileInfoCacheLifetime
FileNotFoundCacheLifetime

PS:
mit Windows 2000 wäre das nie passiert.
mit Windows XP eventuell auch nicht

da gab es ja auch nur SMB1 ...

[Tom]

50 Prozent Datenverlust haben ganz sicher andere Gründe als OpLocking oder Metadatencaching, nämlich hausgemachte. Wie wär's mal mit etwas Beispielcode?

[xbaseklaus]

Guten Morgen , erstmal DANKE für eure Antworten !

Ich habe jetzt erstmal auf der Arbeitsstation mit regedit DirectoryCacheLifetime auf 0 gesetzt !

Danach tritt bei DBAppend im Moment kein Datenverlust mehr auf ...

Auf dem anderen Windows 7 Pc der sowohl Arbeitsstation als auch Server ist habe ich NICHTS geändert ! Soll ich da auch Änderungen in der REG vornehmen ?


Ein anders Problem was ich habe , das beim Starten des Hauptprogramms auf dem Server ( beim Start lege ich alle Index Dateien neu an !!!)
er beim Anlegen der Index Dateien ab und zu einen Fehler bringt

Code: Alles auswählen

 ------------------------------------------------------------------------------
ERROR LOG of "C:\T13082015\..." Date: 08/14/2015 09:13:31

Xbase++ version     : Xbase++ (R) Version 1.82.306
Operating system    : Windows  06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: C VALUE: lartikel.NTX
          -> VALTYPE: C VALUE: artikelnr
          -> VALTYPE: B VALUE: {|| artikelnr}
          -> VALTYPE: U VALUE: NIL
oError:canDefault   : Y
oError:canRetry     : Y
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Operating system error
oError:filename     : 
oError:genCode      :         40
oError:operation    : DbCreateIndex
oError:osCode       :          1
oError:severity     :          2
oError:subCode      :          4
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          1
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Called from MAIN(167)

Meiner Meinung ist das so wenn er aus irgendeinem Grund auf der andern Arbeitsstation aussteigt und ich neu Starten muss ... kann mich aber auch täuschen.

Irgendwelche Anregungen ?

Ach ja auf dem Windows 7 Pc der als Server fungiert ist eine SSD eingebaut ! Gibt es mit SSD Probleme ?

Und ich habe die Energieoptionen so eingestellt dass die PC's NIEMALS in den Standby gehen !

mfg Klaus

[brandelh]

Ich habe nur noch SSD und keine Probleme.
Den Patch von Alaska würde ich auf jedem Rechner einspielen, auch auf Servern.

1. hast du keine "echten" Server
2. auf Server können Terminaldienste laufen (früher Citrix) und das sind auch lokale Anwendungen.
3. Sicher ist sicher

Bei SSD ist für Windows 7 meist ein Tool nötig, da die Defragmentierung abschaltet etc.
Ab 8 soll Windows SSDs automatisch richtig behandeln.

[Wolfgang Ciriack]

Du solltest im Gerätemanager bei der Netzwerkkarte unter Energieoptionen auch noch
"Computer kann das Gerät ausschalten, um Energie zu sparen" deaktivieren.

[Tom]

Kann auch ein reinfunkender Virenscanner verursachen.

[xbaseklaus]

@ Tom

auf der Arbeitsstation ist AVIRA Free
und auf der Arbeitsstation/Server Kombination ist GDATA

Gibt's da Erfahrungswerte , wenn ja ... muss ich bei beiden Virenprogrammen was umstellen / oder kann ich überhaupt was umstellen ?

mfg Klaus

[xbaseklaus]

@Wolfgang OK - da muss ich nochmal über TeamViewer nachschauen - DANKE

[Tom]

Datenordner immer als Ausnahmen definieren, also aus dem Scan ausblenden. Sonst erzeugt der Echtzeitscan irgendwann Dateiöffnungsfehler (kaskadierende Timeouts)9.

[brandelh]

am Besten zusätzlich alle DBF, DBT, FTP, NTX, CDX Dateien von Scannen ausnehmen.

[Werner_Bayern]

Xbase++ (R) Version 1.82.306

Vielleicht mal updaten? Wir schreiben das Jahr 2015...
Aktuell ist

Xbase++ (R) Version 2.00.575

[Jan]

Nachdem mein Kunde seine Serverlandschaft aufgemotzt hat und auf Server 2012R2 umgestiegen ist, sind bei mir auch stapelweise daten verloren gegangen. Neue Sätze wurden z. B. angelegt, aber nicht gefüllt.

In den Griff habe ich das bekommen, indem ich nach dem Abschluß eines Satzschreibens ein DbSkip(0) und ein DbCommit() gesetzt habe. Damit war das komplett behoben.

Jan

[Manfred]

und selbst das klappt nicht zuverlässig. Ich speicher mir die Satzid in eine Tabelle. Das klappt erst absolut fehler- und verlustfrei, seit dem ich die Tabelle Exclusive öffne, den Satz wegschreibe und sofort wieder schließe.

[brandelh]

Wenn die SMB2 Settings nicht stimmen, hilft gar nix.
Ansonsten habe ich auch gehört dass das alte dbSkip(0) nicht mehr zuverlässig sein soll (bestimmt eine Optimierung).
Aber DbGoto(recno()) soll immer noch einwandfrei funktionieren. Ganz vorsichtige merken sich die RecNo() und hauen noch ein dbGoTop() dazwischen ...

[Jan]

Hallo Hubert,

Danke für den Hinweis mit dem DbSkip(0). Wie geschildert klappt das bei meinem Kunden mit der Kombination aus DbSkip(0) und DbCommit(). Aber Verbesserungspotential ist natürlich imemr herzlich willkommen.

Jan

[brandelh]

ich habe auch immer dbskip(0) genommen und vor Win 7 nie Probleme mit dem cache gehabt, aber man weiß ja nie ...

Es kann sein, dass die Probleme aber auch durch SMB2 Patch beseitigt worden wären und die dbGoto(recno())) vorher geändert wurden ... wer weiß sowas im nachhinein noch so genau ...

[AUGE_OHR]

Ein anders Problem was ich habe , das beim Starten des Hauptprogramms auf dem Server ( beim Start lege ich alle Index Dateien neu an !!!)

hm ... vom Server oder von Client aus ?
... oder von beiden (gleichzeitig ... )

du solltest dir mal Gedanken machen "warum" du Index Probleme hast statt die jedes mal neu aufzubauen

Code: Alles auswählen

Xbase++ version     : Xbase++ (R) Version 1.82.306

unabhängig das die v1.8x kein visual Style hat sind IMHO die "Einstellungen" in der original DBESYS "anders".
überprüfe mal, mit DbInfo, die Werte von DBFDBE (DATA-Komponente) und NTXDBE (ORDER-Komponente)

[xbaseklaus]

Guten Abend, leider kämpfe ich noch immer mit Ungereimtheiten ...

Mein aktuelles Problem in diesem Zusammenhang ist folgendes:

Beim Anlegen von Artikeln die zu einer Rechnung gehören verwende ich eine Interne-Nummer die in einer Datenbank abgelegt ist und nach jeder Rechnung
um +2 erhöht wird (bzw. sollte )

Die interne Nummer wird nach dem Anlegen der Rechnung erhöht bzw sollte es:

Code: Alles auswählen

select 12
mit flock gesperrt
und dann
replace nummer with nummer+2
erhöht

Jetzt habe ich aber festgestellt , daß er manchmal trotz replace und ohne eine Fehlermeldung die Nummer nicht erhöht wird !!!
Somit wird dann die gleiche Nummer nochmal vergeben was natürlich nie passieren dürfte und ein Chaos verursacht !!!

Jetzt meine Frage ... warum schreibt er die Erhöhung der Nummer nicht ( nur manchmal nicht ) und ohne Fehlermeldung ?
Habe vorhin mehrmals versucht den Fehler zu provozieren - vergebens??? Aber es passiert beim Kunden ?

Wie könnte ich eine Sicherheitsüberprüfung einbauen um beim nicht Hochzählen und abspeichern der Nummer dies zu erkennen und zu korrigieren ?

für Vorschläge wäre ich sehr dankbar !

mfg.

[Werner_Bayern]

Servus Klaus,

kann eigentlich nicht sein, wenn die Datei wirklich mit flock gesperrt ist, weil das nicht 2x gleichzeitig der Fall sein kann. Du solltest aber unbedingt noch ein dbcommit() nach dem replace machen.

Überprüfen ist doch einfach, nach dem replace und dem dbcommit prüfen, ob es den Eintrag wirklich nur 1x mit der Erhöhung gibt und dann erst die Datei freigeben.

[xbaseklaus]

Also dort wo im Code steht

Code: Alles auswählen

select 12
netflock(10)
replace ...

funktioniert es immer !

da wo steht

Code: Alles auswählen

select 12
use anzahl
netflock(10)
replace...

gibt es Probleme ! kann es an dem eigentlich unnötigen Extra "use anzahl" liegen

mfg. Klaus

[AUGE_OHR]

kann es an dem eigentlich unnötigen Extra "use anzahl" liegen

wir kämen der Antwort näher wenn man auf NETERR() prüfen würde und der Rückgabe Wert von "FLOCK" ausgewertet würde ...

p.s. warum nicht EXCLUSIVE die "Zähler" Datei kurz auf-/zu-machen ?

[xbaseklaus]

@ Werner : habe jetzt ein DBcommit() eingepflegt

@Jimmy : Ich überprüfe ja ob da Flock() erfolgreich war

Code: Alles auswählen

function NetFlock(nTries)
local nWaitTime := 0.2
local lOK 
do while nTries > 0
if flock() = .F.
....

neterr() funktioniert leider nicht bei mir ... warum auch immer !?!

Die Exclusive Methode wäre jetzt der nächste Schritt gewesen , wenn sich das nicht bessert !

Ich habe nach SELECT auf jeden Fall erstmal den unnötigen Befehl "USE ANZAHL" weggelassen

mfg. Klaus