Zugriffproblem auf DBF bei Terminalserver
Moderator: Moderatoren
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Zugriffproblem auf DBF bei Terminalserver
Hallo,
habe bei einem Kunden ein Problem, was ich sonst woanders noch nie hatte.
Auf einem Terminalserver haben die User jeder ein eigenes Verzeichnis mit einigen "lokal" exclusiv genutzten Datenbanken.
Jetzt kommt es ab und zu vor, das plötzlich ein User bei Zugriff auf diese DBFs einen Fehler beim Start bekommt.
Beim Start werden die Dbfs reorganisiert. Die DBF-Datei bekommt dabei plötzlich die Endung .$$$ und Programm bekommt dann Fehlermeldung.
Löschen des Verzeichnisses nutzt nichts (wird automatisch bei Programmstart neu angelegt und die exclusiv genuzten DBFs neu reinkopiert).
Bisher half bei dieser Fima ein Umlegen auf einen anderen Terminalserver (haben mehrere), aber das war natürlich nur ein Hilfskonstrukt.
Virenscanner ist nicht, User haben volle Zugriffsrechte auf diesen Ordner.
Sind diese User-Verzeichnisse auf lokalem Laufwerk installiert, gibt es keine Probleme.
Hat noch jemand eine Idee, woran das liegen könnte ?
habe bei einem Kunden ein Problem, was ich sonst woanders noch nie hatte.
Auf einem Terminalserver haben die User jeder ein eigenes Verzeichnis mit einigen "lokal" exclusiv genutzten Datenbanken.
Jetzt kommt es ab und zu vor, das plötzlich ein User bei Zugriff auf diese DBFs einen Fehler beim Start bekommt.
Beim Start werden die Dbfs reorganisiert. Die DBF-Datei bekommt dabei plötzlich die Endung .$$$ und Programm bekommt dann Fehlermeldung.
Löschen des Verzeichnisses nutzt nichts (wird automatisch bei Programmstart neu angelegt und die exclusiv genuzten DBFs neu reinkopiert).
Bisher half bei dieser Fima ein Umlegen auf einen anderen Terminalserver (haben mehrere), aber das war natürlich nur ein Hilfskonstrukt.
Virenscanner ist nicht, User haben volle Zugriffsrechte auf diesen Ordner.
Sind diese User-Verzeichnisse auf lokalem Laufwerk installiert, gibt es keine Probleme.
Hat noch jemand eine Idee, woran das liegen könnte ?
Viele Grüße
Wolfgang
Wolfgang
- Martin Altmann
- Foren-Administrator
- Beiträge: 16508
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
Wolfgang,
Du bist Dir sicher, dass es keinen Virenscanner (oder ähnliches) gibt?
Dann fällt mir nur noch ein: DEP ausschalten! War auch schon mehrfach Thema hier im Forum. Sollte aber eigentlich mit 1.9 und höher kein Problem mehr darstellen.
Viele Grüße,
Martin
Du bist Dir sicher, dass es keinen Virenscanner (oder ähnliches) gibt?
Dann fällt mir nur noch ein: DEP ausschalten! War auch schon mehrfach Thema hier im Forum. Sollte aber eigentlich mit 1.9 und höher kein Problem mehr darstellen.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo Wolfgang !
Process Monitor auf deine DBFs ansetzen mit folgenden Filter-Einstellungen: Dann siehst du wer an deinen DBFs rumfummelt.
Eventuell auch mit anderen Funktionen wie ReadFile probieren ...
Viel Erfolg
Process Monitor auf deine DBFs ansetzen mit folgenden Filter-Einstellungen: Dann siehst du wer an deinen DBFs rumfummelt.
Eventuell auch mit anderen Funktionen wie ReadFile probieren ...
Viel Erfolg
--
Hans-Peter
Hans-Peter
- Martin Altmann
- Foren-Administrator
- Beiträge: 16508
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
HaPe, die $$$-Dateien werden z.B. angelegt, wenn man DbSort() nutzt.
Viele Grüße,
Martin
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9357
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 101 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
Ja, die Endung .$$$ steht für temporäre Tabellen, die u.a. bei DbPack, DbSort und ähnlichen Vorgängen entstehen. Du schmierst dabei ab, dass diese Temp-Datei(en) die Originaldatei(en) überschreiben soll(en). Das ist ein Rechte- oder Rollenproblem, je nach Struktur des Netzes.
Herzlich,
Tom
Tom
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
Vielen Dank für eure Infos, dann werde ich mal mit dem Netzwerkbetreuer auseinandersetzen.
Viele Grüße
Wolfgang
Wolfgang
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
Also mit Process Monitor geschaut, da greift nur mein Programm zu.
Rechte auf dem Verzeichnis sind auch alle vorhanden, kann nachdem mein Programm abgeschmiert ist, die .$$$-Datei wieder umbenennen, löschen etc.
Bleibt nur noch DEP, da muss ich erst nochmal recherchieren, wie und wo man das unter Server 2019 konfigurieren kann.
Merkwürdig nur, das es eine ganze Weile lief, dann auf einmal bei ein, zwei Usern nicht mehr. 5-6 andere können weiterhin ohne Probleme arbeiten.
Rechte auf dem Verzeichnis sind auch alle vorhanden, kann nachdem mein Programm abgeschmiert ist, die .$$$-Datei wieder umbenennen, löschen etc.
Bleibt nur noch DEP, da muss ich erst nochmal recherchieren, wie und wo man das unter Server 2019 konfigurieren kann.
Merkwürdig nur, das es eine ganze Weile lief, dann auf einmal bei ein, zwei Usern nicht mehr. 5-6 andere können weiterhin ohne Probleme arbeiten.
Viele Grüße
Wolfgang
Wolfgang
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
habe keinen Terminal Server in Betrieb also kann ich es nicht überprüfen.Wolfgang Ciriack hat geschrieben: ↑Do, 07. Mai 2020 19:35 Rechte auf dem Verzeichnis sind auch alle vorhanden,
es it IMHO kein "Rechte" sondern "Timeing" Problem
Aktionen wo solche .$$$ entstehen können sind doch lokal ... und die landen im "lokalen Cache"Wolfgang Ciriack hat geschrieben: kann nachdem mein Programm abgeschmiert ist, die .$$$-Datei wieder umbenennen, löschen etc.
probiere mal ob der SMB2-Patch von Alaska hilft.
gruss by OHR
Jimmy
Jimmy
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo Wolfgang !
Der ITler hatte den Terminal-Server so eingestellt gehabt, dass ein Überschreiben von Dateien nicht möglich war, aber vorher die Zieldatei löschen und dann Kopieren ging.
Nachdem er mir andere ?? Rechte gegeben hatte, hat auch das Überschreiben funktioniert
Das was Tom geschrieben hat, habe ich vor kurzen erlebt.Du schmierst dabei ab, dass diese Temp-Datei(en) die Originaldatei(en) überschreiben soll(en). Das ist ein Rechte- oder Rollenproblem, je nach Struktur des Netzes.
Der ITler hatte den Terminal-Server so eingestellt gehabt, dass ein Überschreiben von Dateien nicht möglich war, aber vorher die Zieldatei löschen und dann Kopieren ging.
Nachdem er mir andere ?? Rechte gegeben hatte, hat auch das Überschreiben funktioniert
--
Hans-Peter
Hans-Peter
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo HaPe,
das würde es vielleicht erklären, wenn es generell nicht funktioniert. Aber es sind z.Zt. nur 2 Useraccounts betroffen, und diese funktionierten auch eine Weile, bis plötzlich das Problem auftauchte.
das würde es vielleicht erklären, wenn es generell nicht funktioniert. Aber es sind z.Zt. nur 2 Useraccounts betroffen, und diese funktionierten auch eine Weile, bis plötzlich das Problem auftauchte.
Viele Grüße
Wolfgang
Wolfgang
- HaPe
- 1000 working lines a day
- Beiträge: 996
- Registriert: So, 15. Nov 2015 17:44
- Wohnort: 71665 Vaihingen-Enz
- Hat sich bedankt: 17 Mal
- Danksagung erhalten: 15 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo Wolfgang !
Die Rechte/Rollen dieser beiden User sind nicht dieselben (oder wurden geändert) wie bei den Usern die keine Probleme haben ...
Ich würde das genau andersrum interpretieren.das würde es vielleicht erklären, wenn es generell nicht funktioniert. Aber es sind z.Zt. nur 2 Useraccounts betroffen, und diese funktionierten auch eine Weile, bis plötzlich das Problem auftauchte.
Die Rechte/Rollen dieser beiden User sind nicht dieselben (oder wurden geändert) wie bei den Usern die keine Probleme haben ...
--
Hans-Peter
Hans-Peter
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 133
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 18 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo Wolfgang,
diese Probleme kenne ich aus eigenen Erfahrungen, kann mir deren Ursache nicht ganz ergründen, hoffe aber darauf, dass es der Versuch des Betriebssystems ist, die Dateioperationen schnell geschehen zu lassen. Sobald man nicht mehr davon ausgeht, dass das die O/S-Funktion DeleteFile nach Rückkehr die Datei auch wirklich gelöscht hat, verschwinden die Probleme. Man muss warten, bis die Datei wirklich weg ist.
Das mache ich an Stellen, wo ich die direkte Kontrolle habe, so:
--- snip ---
STATIC FUNCTION FEraseRetry(file)
LOCAL n
* File not even there? good!
IF .NOT. File(file)
RETURN 0
ENDIF
FOR n := 1 TO 10
* File not there any more? good.
IF .NOT. File(file)
RETURN 0
ENDIF
* File deletion worked? good.
IF FErase(file) == 0
RETURN 0
ENDIF
* Wait a little, then try again
Sleep(10)
NEXT n
RETURN -1
--- snap ---
Dasselbe passiert wahrscheinlich dem Xbase Runtime System mit den dbf Dateien, die eigentlich soeben gelöscht wurden. Wenn die $$$-Datei umbenannt wird, existiert die dbf-Datei doch noch und es schlägt fehl. Der Rest ist Dein Effekt. Ich habe es an dieser Stelle noch nicht erlebt, weil meine dbf-Dateien eigentlich immer im Netzwerk liegen. Deswegen vermute ich ja diesen Optimierungs-Effekt, den Windows eben nur bei Dateien anwenden kann, die lokal liegen. Bei mir waren das auch immer Dateien von kleiner Größe, um nicht zu sagen von großer Kleine. Trifft bei Dir vielleicht auch zu.
Ich habe festgestellt, dass Xbase die Rückgabewerte der Filefunktionen des Betriebssystems nicht immer sauber auswertet und gehe nicht davon aus, dass die mögliche Verzögerung bei der Löschung einer Datei berücksichtigt wird. Das ließe sich aber rausfinden.
Probier es mal mit einem Netzwerklaufwerk. Wenn es da geht: Guten Morgen liebes Betriebssystem, vielen Dank, Du meinst es zu gut.
Viele Grüße
Michael
diese Probleme kenne ich aus eigenen Erfahrungen, kann mir deren Ursache nicht ganz ergründen, hoffe aber darauf, dass es der Versuch des Betriebssystems ist, die Dateioperationen schnell geschehen zu lassen. Sobald man nicht mehr davon ausgeht, dass das die O/S-Funktion DeleteFile nach Rückkehr die Datei auch wirklich gelöscht hat, verschwinden die Probleme. Man muss warten, bis die Datei wirklich weg ist.
Das mache ich an Stellen, wo ich die direkte Kontrolle habe, so:
--- snip ---
STATIC FUNCTION FEraseRetry(file)
LOCAL n
* File not even there? good!
IF .NOT. File(file)
RETURN 0
ENDIF
FOR n := 1 TO 10
* File not there any more? good.
IF .NOT. File(file)
RETURN 0
ENDIF
* File deletion worked? good.
IF FErase(file) == 0
RETURN 0
ENDIF
* Wait a little, then try again
Sleep(10)
NEXT n
RETURN -1
--- snap ---
Dasselbe passiert wahrscheinlich dem Xbase Runtime System mit den dbf Dateien, die eigentlich soeben gelöscht wurden. Wenn die $$$-Datei umbenannt wird, existiert die dbf-Datei doch noch und es schlägt fehl. Der Rest ist Dein Effekt. Ich habe es an dieser Stelle noch nicht erlebt, weil meine dbf-Dateien eigentlich immer im Netzwerk liegen. Deswegen vermute ich ja diesen Optimierungs-Effekt, den Windows eben nur bei Dateien anwenden kann, die lokal liegen. Bei mir waren das auch immer Dateien von kleiner Größe, um nicht zu sagen von großer Kleine. Trifft bei Dir vielleicht auch zu.
Ich habe festgestellt, dass Xbase die Rückgabewerte der Filefunktionen des Betriebssystems nicht immer sauber auswertet und gehe nicht davon aus, dass die mögliche Verzögerung bei der Löschung einer Datei berücksichtigt wird. Das ließe sich aber rausfinden.
Probier es mal mit einem Netzwerklaufwerk. Wenn es da geht: Guten Morgen liebes Betriebssystem, vielen Dank, Du meinst es zu gut.
Viele Grüße
Michael
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo Michael,
danke für deine Info. Aber wie soll ich Dateien, die auf einem Terminalserver liegen verschieben ??
danke für deine Info. Aber wie soll ich Dateien, die auf einem Terminalserver liegen verschieben ??
Viele Grüße
Wolfgang
Wolfgang
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 133
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 18 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
Hallo Wolfgang,
mach eine Testversion von Deinem Programm, die die Daten auf einem Netzwerklaufwerk jenseits des Terminalservers jongliert. Ich kenne Deine Verzeichnis-Struktur und -Arithmetik nicht, deswegen kann ich nichts Konkretes sagen. Ich wollte auch nur einen möglichen Ansatzpunkt aufzeigen.
Wie ich schrieb, ich habe am Ende keine Beweise für meine Annahmen, erinnere mich nur an die File-Fata-Morganen und den Impfstoff gegen die Symptome, der mittlerweile klinisch erprobt ist. Ich weiß noch nicht mal, ob die Impfung noch sinnvoll ist. Aber Dein Fall lässt sie ratsam erscheinen.
Viele Grüße
Michael
mach eine Testversion von Deinem Programm, die die Daten auf einem Netzwerklaufwerk jenseits des Terminalservers jongliert. Ich kenne Deine Verzeichnis-Struktur und -Arithmetik nicht, deswegen kann ich nichts Konkretes sagen. Ich wollte auch nur einen möglichen Ansatzpunkt aufzeigen.
Wie ich schrieb, ich habe am Ende keine Beweise für meine Annahmen, erinnere mich nur an die File-Fata-Morganen und den Impfstoff gegen die Symptome, der mittlerweile klinisch erprobt ist. Ich weiß noch nicht mal, ob die Impfung noch sinnvoll ist. Aber Dein Fall lässt sie ratsam erscheinen.
Viele Grüße
Michael
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2121
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 72 Mal
Re: Zugriffproblem auf DBF bei Terminalserver
Servus Wolfgang,
ich kann da Michael nur zustimmen. Du hast das Problem sicherlich - wie Tom schrieb - beim DbPack() - Befehl.
Wir verwenden den schon sehr lange deswegen nicht mehr, sondern machen ein copy to, danach ein commit, löschen bei Erfolg die Ursprungsdateien und benennen die neu erzeugten mit frename zurück. Damit hast Du alles selber unter Kontrolle, kannst jeden Vorgang prüfen (ferase, frename haben Rückgabewerte). Dazwischen kannst dann nach Bedarf ein Sleep(1) einbauen, dann dürften Deine TS-Probleme Geschichte sein.
ich kann da Michael nur zustimmen. Du hast das Problem sicherlich - wie Tom schrieb - beim DbPack() - Befehl.
Wir verwenden den schon sehr lange deswegen nicht mehr, sondern machen ein copy to, danach ein commit, löschen bei Erfolg die Ursprungsdateien und benennen die neu erzeugten mit frename zurück. Damit hast Du alles selber unter Kontrolle, kannst jeden Vorgang prüfen (ferase, frename haben Rückgabewerte). Dazwischen kannst dann nach Bedarf ein Sleep(1) einbauen, dann dürften Deine TS-Probleme Geschichte sein.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>