Bertram Hansen hat geschrieben:
ich habe mir mal einige von den Einstellungen näher angesehen und teilweise auch ausprobiert.
...
Kommentare oder andere Auffassungen sind ausdrücklich erwünscht.
Danke erstmal für deinen Beitrag, so hatte ich mir das vorgestellt !
Die Settings für Xbase++ sind aus dem Vortrag vom Usertreffen "geklaut" und werden von Alaska
"empfohlen" für ( Win OS() ? ) Netzwerke.
wie man an der Umfrage sieht "kenne" ich auch nicht alle und werde deshalb nur die "Empfehlung"
auflösen die zu dem Registry Eintrag steht.
Bertram Hansen hat geschrieben:
zu autodisconnect:-1
Im Falle eines Fehlers müsste im Netzwerk doch dann der DOS Fehler 5 Zugriff verweigert auftreten oder ???
Yup und ähnliches bei geöffneten DBF/Index und einer "Bewegung"
Auto-Disconnet des Servers ausschalten (Q297684):
Problem : -1 oder ffffffff
Bertram Hansen hat geschrieben:
zu SharingViolationDelay = 0 bzw. SharingViolationRetries = 0
Betrifft meiner Meinung nach doch nur Dateien die Exclusive geöffnet wurden oder ???
Nein
I/O-Performance
Typische Phänomene: USE von Tabelle oder Index dauert lange (~1s)
Bertram Hansen hat geschrieben:
zu DisableFlushOnCleanup = 1
Dieses Problem wurde erstmals in Microsoft Windows XP Service Pack 2 behoben.
ah ja
Problem : DbAppend()/DbCommit() sind langsam
Bertram Hansen hat geschrieben:
zu OplocksDisable = 1
Verzögert die Programmausführung erheblich.
ja, aber "sicherer" ... und hast du auf dem Server EnableOplocks= 0 gesetzt ?
http://support.microsoft.com/kb/296264Hinweis: Durch den Eintrag "EnableOplocks" werden Windows-Server so konfiguriert, dass auf ihnen opportunistisches Sperren bei lokalen Dateien zugelassen oder abgelehnt werden kann. Diese Server enthalten Arbeitsstationen, die Dateien freigeben.
und
Hinweis: Der Eintrag "OplocksDisabled" bestimmt, ob Windows-Clients für eine Remotedatei opportunistisches Sperren anfordern oder nicht.
man muss also
BEIDE Schalter setzten sonst "wirken" die nicht !!!
das "Problem" dabei ist das es erst bei "Belastung" auftritt, also bei meinen Kunden am Mo. / Di.
wo nach dem Wochenende "die Hölle tobt". Auch ist es von der Hardware abhängig (Cache / RAM)
wann das "Problem" auftritt und wie bei Computer üblich "digital" 0/1 Crash oder nicht Crash ...
dabei ist es nicht nur ein Xbase++ "Problem" sondern auch mit Cl*pper kann ich das selbe
"provozieren" und soviel "Last" erzeugen das es crasht ... auch unter Novell wenn Oplocks nicht
"disable" wurde.
einen ähnlichen Effect kann man bei USB Sticks "simulieren" wenn man die auf "Leistung" statt
default "sicheres entfernen" eingestellt hat. Wenn man mit FWrite() Blöcke auf den USB Stick
schreibt und dabei die Grösse der Blöcke erhöht so wird irgendwann die Übertragung "stocken".
wenn man jetzt den USB Stick abziehst dann hast man verloren ... evtl. USB Stick defekt.
hat man aber "sicheres entfernen" eingestellt geht der Progressbar immer gleichmässig weiter
egal wie gross die Blöcke werden UND du kannst jederzeit den USB Stick abziehen (theoretisch...)