OrdCreate Fehler 66

[Werner_Bayern]

Servus Jimmy,

nein, es sind keine anderen Applikationen auf dem NAS oder Daten, auf die zugegriffen wird.

Die Erfahrungen durch Tests, die wir in diesem Zusammenhang gemacht haben, sind etwas anders, als Du geschrieben hast. Es reicht, wenn eine XP-Station eine Datei auf dem 2008er geöffnet hat und ein index on durchführt. Dann hat es schon bei ca. 8 von 10 Versuchen geknallt. Anfangs glaubten wir zu erkennen, dass es auch einen Unterschied macht, ob die Test-Index-Datei schon existiert und durch den index-Befehl überschrieben wird, das war jedoch nicht 100%ig nachzuvollziehen.
Aber die Probleme treten schon verstärkt beim Erzeugen von Dateien (copy to, index on) und anschließendem, sofortigem Zugriff darauf auf.

[Werner_Bayern]

Servus Jimmy,

wir hatten vorher folgende Konstellation bei dem Kunden:

Applikation auf X:\win-ww
Daten auf X:\ww (wg. alter DOS-Version)

Start am XP-Client (und auch bei allen anderen) über eine Verknüpfung: x:\win-ww\ww.exe
und die Applikation öffnet dann alle Dateien per UNC auf \\server\freigabename\ww (nicht win-ww).

Die Pfade in einer früheren Mail waren nur ein Beispiel, hier war es konkret so.

Dann hätte Dein beschriebenes SMB-Problem nicht auftreten dürfen?

[georg]

Hallo, Werner -


hast Du in dem Fall mal versucht, ein Sleep(100) (plus minus n) nach dem copy to/index to etc. einzusetzen?

[Werner_Bayern]

hast Du in dem Fall mal versucht, ein Sleep(100) (plus minus n) nach dem copy to/index to etc. einzusetzen?

Servus Georg,

nein, weil es ja auch beim ordcreate schon knallt und ich da keine Möglichkeit gehabt hätte.

[georg]

Hallo, Werner -


dann habe ich Dich hier missverstanden:

Aber die Probleme treten schon verstärkt beim Erzeugen von Dateien (copy to, index on) und anschließendem, sofortigem Zugriff darauf auf.

Das "anschliessendem" brachte mich auf den Gedanken, mal eine (erzwungene) Pause einzulegen.

[Werner_Bayern]

Verständlich, aber bei Ordcreate ist es ja auch so, ohne dass ich da eingreifen könnte. Index-Datei wird erzeugt und dann mit Daten gefüllt. Auch bei copy to ist es ja so. Es knallt ja schon bei den internen Funktionen von Xbase++, da wird die nächste Befehlszeile von mir ja noch gar nicht ausgeführt.

[Koverhage]

Aus meiner Erfahrung kann ich nur folgendes sagen:
1. OrdCreate scheitert, wenn die DBF datei defekt ist, oder die Index-Datei Schrott ist (diesen Fall hatte ich vor kurzem)
2. in 99,99% der Virenscanner

Wenn der Virenscanner ausgeschlossen werden kann (normal nur wenn der komplett zum Test deaktiviert wird)
würde ich mal Fall 1 prüfen.

[brandelh]

Windows 7 (Server 2008) ohne die 3 Cache Schalter sind auch tötlich für die Indexe, wie ich hier immer wieder feststellen muss.

[Werner_Bayern]

Servus Klaus,

1:1 auf das NAS gelegt, aktuell keine Probleme mehr. Die DBF ist in Ordnung, war ja nur das Problem von XP-Stationen aus.

[AUGE_OHR]

hi,

Die Erfahrungen durch Tests, die wir in diesem Zusammenhang gemacht haben, sind etwas anders, als Du geschrieben hast.

ok, scheint als das du nicht das klassische "Ops-lock" Problem meinst.

Es reicht, wenn eine XP-Station eine Datei auf dem 2008er geöffnet hat und ein index on durchführt.

du redest also jetzt von "ein und der selben" Workstation ?!

Aber die Probleme treten schon verstärkt beim Erzeugen von Dateien (copy to, index on) und anschließendem, sofortigem Zugriff darauf auf.

hm ... alles "auf" dem Server ?

Start am XP-Client (und auch bei allen anderen) über eine Verknüpfung: x:\win-ww\ww.exe
und die Applikation öffnet dann alle Dateien per UNC auf \\server\freigabename\ww (nicht win-ww).

du startest also die Xbase++ Application "vom W2k8 Server" (?) über ein ge-"map"-tes Laufwerk ...
diese "Variante" funktioniert IMHO nur dann wenn der Client Desktop "auf dem Server" liegt und das geht erst ab Win7.
alle %USER% Verzeichnisse werden dann auf das \\Server\%USER% umgeleitet.

Frage : schon mal versucht die Xbase++ Applikation "vom Client" laufen zu lassen ?

wenn du aber von "Index" redest wird der doch im TMP erzeugt und der ist gewöhnlich auf dem Client

TMP=<Verzeichnis>
Im TMP Verzeichnis werden temporäre Dateien angelegt, z.B. wenn INDEX ON oder DbSort() ausgeführt wird.

Frage : hast du die "lokal" genutzten Verzeichnisse freigegeben ?

Windows 7 (Server 2008) ohne die 3 Cache Schalter sind auch tötlich für die Indexe, wie ich hier immer wieder feststellen muss.

und hat mit der vorherigen Frage zu tun.

in einem SMB2 Netzwerk muss der Server "wissen" was los ist weil jede "Aktion" eine eigene Authentifizierung erhält. das funktioniert aber nur mit "freigegebene" UNC Path Ordner. (oder dem Explorer)

wenn ein Client sich eine DBF nimmt und nun ein Index, welcher zunächst temporär erzeugt wird, erstellt und "sofort" damit "arbeiten" will dann knallt es genau so wie bei ZAP.

Auch bei copy to ist es ja so.

sind Quelle und Ziel beide UNC Path ? beides auf dem Server ?

Frage : wir reden doch hier vom Xbase Befehl "copy to" ... ist da noch eine "Bedingung" dran oder willst du "nur" eine "Datei kopieren" ?

ich sprach ja den Explorer an der ja die ShFile API Functionen für "copy" benutzt. wenn man die API Function unter XP verwendet dann weiss auch der W2k8 Server "Bescheid"

Sleep(100) (plus minus n)

könnte man versuchen ... aber wenn keine "Informationen" eintreffen kann man ewig warten.

bei ZAP soll man die DBF ja schliessen / wieder öffnen. Bei Index würde ich es so versuchen

Code: Alles auswählen

dbUseArea( .F., , "KUNDEN", , iif(.F. .or. .T., !.T., NIL), .F.)  
dbCreateIndex( _name, _key, _EarlyBoundCodeblock({|| &_key}), iif(.F., .T., NIL) )
dbClearIndex()
KUNDEN->( dbCloseArea() )
dbUseArea( .F., , "KUNDEN", , iif(.T. .or. .F., !.F., NIL), .F.)  
ordListClear() ;ordListAdd( _name )

1:1 auf das NAS gelegt, aktuell keine Probleme mehr. Die DBF ist in Ordnung, war ja nur das Problem von XP-Stationen aus.

XP arbeitet eben nur mit SMB1 ... kein SMB2 ... keine SMB2 Probleme

[Werner_Bayern]

Servus Jimmy,

ich antworte mal der Reihe nach

Der Kunde hat noch 2-4 XP-Clients, auf 2 haben wir getestet und die nachvollziehbaren Probleme.
Ja, wie bereits geschrieben, starten wir über ein gemapptes Laufwerk, alles lag auf dem Server. Programmverzeichnis und Datenverzeichnis.
Der Client-Desktop liegt nicht auf dem Server (Roaming Profile? Das geht seit Windows XP, oder meinst Du TS?). Nein, wg. Update-Problematik und Wartung haben wir bisher die App noch nicht lokal gehalten. Wie gesagt, wir nutzen hier keinen Terminalserver oder Remote-Desktop, sondern einfaches mapping.

Nein, es sind auf den XP-Clients keine lokalen Verzeichnisse freigegeben. TMP-Dateien erzeugt nach meinen Beobachtungen bei diesem Kunden Xbase++ direkt im Programmverzeichnis.

Unser Test sah so aus:

Code: Alles auswählen

   use (cDatei) exclusiv
   if neterr()
      @ 8, 2 say "Fehler, Datei kann nicht geöffnet werden!"
   else
      @ 7, 2 say "Erfolgreich geöffnet, Datensätze: " + ltrim(str(lastrec()))
      index on bestellnr to test.ntx
      @ 8, 2 say "Erfolgreich!"
      use
   endif

Die Datei war nicht besonders groß. Es knallte dann schon beim OrdCreate (index on).

copy to: sind Quelle und Ziel beide UNC Path ? beides auf dem Server ?

Ja, beide UNC. Nein, keine Bedingung. Ja, Xbase++ - Befehl.

[Werner_Bayern]

Servus Jimmy,

hab ich das jetzt richtig so von Dir verstanden, zusammengefasst wäre die Lösung gewesen, die Applikation nicht über das gemappte Laufwerk, sondern über den UNC-Pfad zu starten?

[brandelh]

Wenn man die EXE direkt über UNC startet, kann man aber meines Wissens keine Batchdateien mehr ausführen.
Ob RunShell() grundsätzlich nicht geht weiß ich jetzt aber nicht.

[AUGE_OHR]

hab ich das jetzt richtig so von Dir verstanden, zusammengefasst wäre die Lösung gewesen, die Applikation nicht über das gemappte Laufwerk, sondern über den UNC-Pfad zu starten?

man sollte IMHO "überall" UNC-PATH verwenden wobei ich "eine" NET_USE Function einsetzte.

[Werner_Bayern]

ich setze auch eine net_use-Funktion ein und da wird der UNC-Pfad mit übergeben. Trotzdem hat es nicht funktioniert.
Aber nochmal meine Frage, wäre das Problem evtl. erledigt, wenn die APP auch über UNC und nicht über ein gemapptes Laufwerk gestartet worden wäre?