Datenverlust unter Windows 7

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

Frage : was hab ich wohl hier im letzten Fall gemacht ?
und hat keiner eine Antwort darauf ? ... oder "traut" sich keiner ?
gruss by OHR
Jimmy
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von Koverhage »

Jimmy,

ich habe keine Antowrt darauf, warum sollten wir uns nicht trauen ?
Gruß
Klaus
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

Koverhage hat geschrieben:ich habe keine Antowrt darauf
kein Problem, wollte nur mal "testen" ob ihr noch "zuhört"
Koverhage hat geschrieben:warum sollten wir uns nicht trauen ?
vielleicht habe ich ja die Leute "verschreckt" mit so vielen Fakten ...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

ich versuche die Frage noch einmal zu stellen : Was habe ich wohl mit der Win7 Station gemacht das die jetzt auch auf Port 139 "kommuniziert" ?

schaut euch doch bitte noch mal die Bilder an wie sich XP bzw. Win7 verhält dann müsstet ihr auf die Lösung kommen ...
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von UliTs »

Jimmy,
Wie wäre es, wenn Du ein neues Thema "Die schwierigsten Rätsel" aufmachst? :wink:
Du verwendest wirklich viel Zeit mit Deinen Nachrichten! Ich habe oft das Problem, dass ich absolut nicht weiss, was Du mitteilen möchtest. :(
Bist Du der Meinung, dass es keine Probleme mit Windows7 gibt oder das die Lösung ganz einfach ist? Oder genau das Gegenteil? #-o
Und was hat es mit dem Port 139 auf sich?

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

UliTs hat geschrieben:Wie wäre es, wenn Du ein neues Thema "Die schwierigsten Rätsel" aufmachst? :wink:
Du verwendest wirklich viel Zeit mit Deinen Nachrichten! Ich habe oft das Problem, dass ich absolut nicht weiss, was Du mitteilen möchtest. :(
deshalb die vielen Bilder ;)
aber Danke, genau das wollte ich ja wissen ob ich es klar genug ausdrücke.
UliTs hat geschrieben:Bist Du der Meinung, dass es keine Probleme mit Windows7 gibt oder das die Lösung ganz einfach ist? Oder genau das Gegenteil? #-o
Genau diese "Definition" ist doch das "Problem" ...

welche Netzwerk Konfiguration hast du denn ? überprüft ?
welche "Responder" und "Redirector" verwendest du ? überprüft ?

wenn wir nun von den "selben" Test Bedingungen sprechen solltest du die selben Resultate bekommen (siehe Bilder)
UliTs hat geschrieben:Und was hat es mit dem Port 139 auf sich?
Ich hatte gehofft das bei jemanden schon ein "Licht" aufgegangen ist worauf ich raus will.

XP benutzt NetBios Port 139 zum "kommunizieren". XP "verwendet" dabei SMB1
Win7 "kommuniziert" aber gewöhnlich "direkt" über Port 445. Win7 "verwendet" dabei SMB2

wenn ich also Win7 auf Port 139 "gezwungen" habe dann passiert das durch "abschalten" von SMB2.
Durch das "abschalten" von SMB2 laufen dann alle "Anfragen" über Port 445 "ins leere", deshalb sollte man KEINESFALLS SMB2 "komplett" abschalten.

vielmehr sollte man die neuen Möglichkeiten nutzen, wie man es nun machen "sollte" zeigt uns z.B.
c:\ALASKA\XPPW32\Source\samples\basics\DRAGDROP\DROP.EXE

startet es mal und per DragDrop fügt ihr eine "grösse" DBF, welche auf dem Server liegt, ein.
so nun PgDN ( Bild runter ) runter .... runter ... und den Resource Monitor beobachten ...
bei EOF dann wieder rauf ... rauf ... und den Resource Monitor beobachten ...

als Vergleich die selbe DBF nun mit XbpBrowse() statt XbpQuickBrowse().
In einem "pure" Win7 Netzwerk solltet ihr den Unterschied zu einem XP Netzwerk "merken".
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

so nachdem hoffentlich klar ist warum ich zum Anfang (auf Seite 2) Zweifel angemeldet habe möchte ich das ganze noch mal zusammenfassen.

Win7 kann über Port 445 (SMB2) und Port 139 (SMB1) "kommunizieren" wobei SMB2 den "Redirector" MRXSMB20.SYS benutzt

Nur die v.20xxx Version, von MRXSMB20.SYS, weist die "Fehler" auf.
Die Parameter, von Andreas Herdt, beziehen sich ebenfalls auf die v.20xxx Version
der "Hot-Fix" ist ebenfalls eine v20xxx Version

Wenn man nun SMB2 "abschaltet" wird Port 139 benutzt, also SMB1 -> MRXSMB.SYS,
damit ist die MRXSMB20.SYS, welche über Port 445 "kommuniziert", gar nicht "in Betrieb" !!!

Risiko und Probleme, mit Anwendungen die auf Port 445 zugreifen möchten, entstehen dadurch !!!





Ich bin deshalb der Meinung das der "BUG" auf einem "Responder" Fehler beruht der beim "runter-schalten" von SMB2 nach SMB1 im "Mix-Betrieb" geschieht.

Wenn man NetName() verwendet hat bekommt man ja schon den ersten Hinweis und im Eventlog (Ereignisanzeige/System ordnen nach Event) müsste der MRXSMB Fehler aufgeführt sein.

Weiter Hinweis in der DBF, seht euch an was beim "zuschalten" eines weiteren Client in der DBF als NetName() steht.

Wie man nun die "Lock" Zeiten und die Diagramme im Resource Montor "interpretiert" habe ich versucht mit den Bildern darzustellen.
gruss by OHR
Jimmy
Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 483
Registriert: So, 28. Mär 2010 19:21
Danksagung erhalten: 11 Mal

Re: Datenverlust unter Windows 7

Beitrag von azzo »

Ich habe vor einigen Wochen eine Supportanfrage an Microsoft gestellt. Hier die Antwort:

Ich hoffe, die erarbeitete Lösung ist zufriedenstellend für Sie.
Ich fasse die Anfrage noch einmal in Stichpunkten zusammen:

• Symptom - when accessing files on an network share say \\server\share on a Server 2008 (RTM or R2) a self developed application needs 3-7 secs to show the presence of the file
• Ursache - SMB 2.0 negotiation on each connection, protocol design
• Lösung - Disable SMB2.0
Sie können SMB 2.0 auf 2 Wege ausschalten:
Durch einen cmd.exe mit Administratorberechtigungen:

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled


oder durch einen regedit.exe Modifizierung der Registry:

HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters

Value name: Smb2
Value type: REG_DWORD
0 = disabled
1 = enabled



Wenn Sie in aber SMB 2.0 in einen Netzwerkumgebung anwenden müssen, dann implementieren Sie, bitte den folgenden Kommandozeilen in cmd.exe mit Administratorberechtigungen:

Netsh int tcp set global RSS=Disabled
Netsh int tcp set global chimney=Disabled
Netsh int tcp set global autotuninglevel=Disabled
Netsh int tcp set global congestionprovider=None
Netsh int tcp set global ecncapability=Disabled
netsh int ip set global taskoffload=disabled
Netsh int tcp set global timestamps=Disabled

Wenn Sie weitere Fragen zu diesen Thema haben, bitte melden Sie sich bei mir per E-mail und ich würde Ihnen gerne antworten. Bis dann verbleibe ich,
mfg
Otto
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

azzo hat geschrieben:Ich habe vor einigen Wochen eine Supportanfrage an Microsoft gestellt. Hier die Antwort:
Danke für den Hinweis wie man SMB2 "abstellt" was ich NICHT empfehlen würde ...

Anmerkung : Ich "meine" es gibt noch eine weitere Möglichkeit statt "komplett" SMB2 "abzuschalten".

In einem "pure" Win7 / Srv2008, welche alle Windows Updates enthält, sollte die Kommunikation nur über SMB2 ( Port 445 ) gehen.
mit der MRXSMB20.SYS v.16xxx und v17xxx ( Win7 Service Pack1 ) kann ich in meinen Netzwerken kein 8889 ( APPEND BLANK ) Problem feststellen.

wenn man nun tatsächlich SMB2 "abschaltet" und über das NTB Layer mit SMB1 ( Port 139 ) geht, dann "wirken" selbstverständlich auch alle SMB1 Ops Locking Parameter.

anders-herum kann man aber auch die

Code: Alles auswählen

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters
OplocksDisabled
"gezielt" einsetzten um zusammen mit

Code: Alles auswählen

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters
UseOpportunisticLocking
verwenden um "nur" das Ops Locking auf SMB1 Niveau "zu drücken"

Man kann dann, im Resource Monitor, beobachten wie Xbase (ohne ++ alle Versionen ) über Port 139 geht aber zusätzlich "andere" Applicationen (z.b. Office 2010), wenn man die öffnet, über Port 445 gehen.

Diese 3th Möglichkeit,im "Mix" Betrieb, ist vom "langsamsten" OS() "abhängig" und kann den Faktor 10x betragen was man dann besonders bei öffnen von Office Documenten, welche auf dem Server liegen, merken kann.

wer PDF zum lesen zu solchen "technischen" Interna sucht findet die hier:
http://msdn.microsoft.com/en-us/library ... 13%29.aspx
gruss by OHR
Jimmy
Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 831
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Hat sich bedankt: 1 Mal
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von satmax »

Danke für die ausführlichen Darstellungen, hat mir sehr geholfen, eine Clipper 5.2 App zum laufen zu bringen (Server 2008R2, lauter W7 Clients).

Markus
Gruß
Markus
CRT
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 123
Registriert: Mo, 18. Aug 2008 9:33
Wohnort: Kärnten / Österreich
Hat sich bedankt: 10 Mal
Danksagung erhalten: 2 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von CRT »

Hallo an alle,

wie ist den die SMB2 Situation jetzt mit dem SP1 von Windows7?
Hat Alaska sein Installationspaket bezüglich der falschen REG-Keys korrigiert?
Hat jemand eine eigene REG-Datei oder ein Setup mit den korrekten REG-Keys geschrieben?

gruß

CRT
Zeiterfassung . Zutrittskontrolle
www.CRT-software.com
:wav:
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von brandelh »

Hallo,

laut Stefens Aussage in Hannover läuft das Installationspaket bei vielen Firmen erfolgreich, daher sollte es funktionieren.
Ich rate zum Ausprobieren ;-)
Eine eigene REG Datei ist natürlich auch schnell erstellt, allerdings braucht die Admin-Rechte - vermutlich die EXE auch :?: .
Gruß
Hubert
CRT
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 123
Registriert: Mo, 18. Aug 2008 9:33
Wohnort: Kärnten / Österreich
Hat sich bedankt: 10 Mal
Danksagung erhalten: 2 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von CRT »

Scheint also ein MUSS zu sein das setup auszuführen?
Zeiterfassung . Zutrittskontrolle
www.CRT-software.com
:wav:
CRT
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 123
Registriert: Mo, 18. Aug 2008 9:33
Wohnort: Kärnten / Österreich
Hat sich bedankt: 10 Mal
Danksagung erhalten: 2 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von CRT »

Hab die smb2-infocache.msi (16384 Bytes) gerade getestet. Schreibt die korrekten REG-Keys!

gruß

CRT
Zeiterfassung . Zutrittskontrolle
www.CRT-software.com
:wav:
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von brandelh »

In der Newsgroup oder war es bei Pablo ... ein Kollege hat geschrieben, dass das oft verwendete:

Code: Alles auswählen

unlock
dbSkip(0)
nicht mehr ausreicht um die Puffer wirklich zu leeren und neu einzulesen.
ich habe bei mir nun eine Funktion geschrieben und es scheint besser geworden zu sein (man soll den Tag nicht vor dem Abend loben ... :? ) ... ;-)

Code: Alles auswählen

*---------------------------------------------------------------------------------------------
function BufferSchreibenLesen( nAlias, WiederSperren ) // Alias der zu puffernden Dateien
   local nAktiveRecNo, nMax := 10, x, nStart := seconds()

   if empty(nAlias)
      nAlias := select()
   endif

   DEFAULT WiederSperren TO .f.
   nAktiveRecNo := (nAlias)->(recno())
   // Nötig für neuen Server: unlock, Satzbewegung und neu locken
   (nAlias)->(dbunlock())            // freigeben
   (nAlias)->(dbgoTop())             // bewegen
   (nAlias)->(dbgoTo(nAktiveRecNo))  // zurück

   if (nAlias)->(recno()) # nAktiveRecNo  // das dürfte nie vorkommen
      msgbox( "Fehler im Datenpuffer festgestellt. Bearbeitung wird beendet, bitte erneut anmelden und Fall prüfen." )
      break
   endif

   if WiederSperren
      x := 1
      do while .t.
         if (nAlias)->(dbRLock())
            exit
         else
            if x > nMax
               msgbox( "Daten wurden gespeichert, aber Datensatz kann nicht mehr gesperrt werden !")
               break
            else
               x++
            endif
         endif
      enddo
   endif

return NIL
*---------------------------------------------------------------------------------------------
function GotoEof( nAlias ) // Alias der zu puffernden Dateien
   local x := 1
   if empty(nAlias)
      nAlias := select()
   endif
   (nAlias)->(dbunlock())            // freigeben
   (nAlias)->(dbGoBottom())
   (nAlias)->(dbSkip())              // das sollte schon gengen !
   do while ! (nAlias)->(eof())
      sleep(0)
      (nAlias)->(dbSkip())
      if x > 100
//--- Fehler loggen oder melden.
         exit
      else    // ergänzt nach Toms Hinweis, aber dies dürfte nie nötig sein.
         x++
      endif
   enddo
return (nAlias)->(eof())
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von Tom »

Mmh. "GoToEof" wird nie aufgerufen, und sie inkrementiert ihren Zähler auch nicht, weshalb IF x > 100 niemals eintritt, was keine Rolle spielt, da die Funktion ohnehin nicht aufgerufen wird - jedenfalls im Beispielcode.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von brandelh »

GoToEof() stand im Quellcode nur darunter und ich habe es mitkopiert, man weiß ja nie wer was brauchen kann ...
Die Anwendung selbst ruft es auf, wenn die Datensätze nicht mehr zum Suchbegriff passen (SCOPE gab es damals noch nicht ;-) )
Aber du hast Recht, die untere Schleife braucht noch ein x++ ... ich hoffe dass das nie nötig wird :D
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von Tom »

Trotzdem, noch ein Mmh. Du entsperrst den Datensatz, gehst zum Anfang und dann wieder zum Datensatz. Dort prüfst Du dann, ob die Datensatznummer übereinstimmt (was tatsächlich immer der Fall sein muss, auch bei Schreibfehlern - eigentlich müsstest Du via FieldGet prüfen, ob der Inhalt übereinstimmt!). Mal davon abgesehen, dass das bei großen zu schreibenden Datenmengen eine spaßige Angelegenheit werden kann (nicht: muss), sehe ich nicht notwendigerweise eine Umgehung von Cache- oder Metadatenproblematiken. Es wird einfach in der Tabelle herumgefuhrwerkt, in der Hoffnung, dass die Herumfuhrwerkerei zufällig auch Probleme löst. Was vielleicht sogar der Fall ist. Aber keine Lösung. Übrigens. Wenn auf der Tabelle ein Filter steht, wird dieser mit diesem Konstrukt mindestens einmal pro Schreibvorgang evaluiert, nämlich beim DbGoTop() (beim DbGoto() nicht).

Ich weiß, es geht in erster Linie darum, ein mögliches Problem zu umgehen. Aber nicht jede "Lösung", die scheinbar funktioniert, ist wirklich eine.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

brandelh hat geschrieben:In der Newsgroup oder war es bei Pablo ... ein Kollege hat geschrieben, dass das oft verwendete:

Code: Alles auswählen

unlock
dbSkip(0)
nicht mehr ausreicht um die Puffer wirklich zu leeren und neu einzulesen.
da "fehlt" ein COMMIT ... und es war auf ein Browse bezogen.

was die Aussage mit "Puffer" und "leeren" hier gesagt wird zeigt das derjenige der dass sagte gar nicht klar ist "was" das Problem ist und "wer" dafür verantwortlich ist.


Es gibt das "application-driven caching" und das "OS driven caching" welches der Netzwerk Client und Server ausführen.

a.) wenn man "local" arbeitet "könnte" man alle DBF EXCLUSIVE öffnen -> niemals "Cache" Probleme
b.) wenn man "alleine" im Netzwerk arbeitet im "share" Modus arbeitet ist das -> SMB "exclusive OpLock"
der Netzwerk Client Cache ist default "off" ... es sei denn der Server "merkt" das man "alleine" die DBF nutzt und schaltet auf "Clientbased Caching" ( lokal )

c.) wenn mehrere im Netzwerk an der selben DBF arbeiten -> SMB "Level 2 OpLocks"
das "Problem" taucht "nur" beim "umschalten" von b.) nach c.) auf wenn die 2nd Workstation auf die DBF zugreifen will.
Nun muss der Server die 1st Workstation "benachrichtigen" das er "sofort" alle Änderungen zurückschreiben soll und in den "Level 2 OpLocks" zurück schalten soll.

dummerweise weiss aber der Netzwerk Client nicht was "in" einem File basierenden Datei ist ... er kopiert nur den Cache hin / her.

angenommen es wäre eine Excel Tabelle dann würde die ganze Tabelle geladen und zurück geschrieben.
bei eine DBF wir der "lock" aber nur in einem "Bereich" ausgeführt und alle Xbase Versionen verwenden deshalb die "Dirty Reads" Technik um ein "blocken" des OS() zu verhindern.

das wäre z.b. der Fall wenn ich mehrere Datensätz "lock" und jemand von einer anderen Station ein Browse ausführen möchte.

mittels der "Dirty Reads" Technik wird nun nicht der "wirkliche" Daten "Bereich" ge-locked sondern wie wir wissen bei 1GB + RECNO() (bzw. 2GB + RECNO() )
es wird also nicht der "wirkliche" Daten "Bereich" gesperrt sodass andere Workstation auch "lesen" können.

und "das" ist das eigentliche Problem denn der Netzwerk Client "sieht" nicht die "locks" am Ende der Datei und damit nicht die "Aktivitäten" der anderen Workstationen sondern schreibt einfach "seine" Änderrungen zurück.

p.s. statt DbGoTop() gehe ich auf den Ghostrec
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von brandelh »

Tom hat geschrieben:Trotzdem, noch ein Mmh. ...
Ich weiß, es geht in erster Linie darum, ein mögliches Problem zu umgehen. Aber nicht jede "Lösung", die scheinbar funktioniert, ist wirklich eine.
Das Problem ist, dass seit der Umstellung auf die neuen Terminal Server 2008 trotz der eingefügten 3 Parameter das - sehr alte - Programm (erste Version Clipper 1993) massive Indexprobleme hatte. Mit dieser Änderung hat sie diese nicht mehr !

Bei neueren Programmen öffne ich die Dateien ausschließlich zum Suchen, Daten lesen und Daten schreiben.
Bei diesen Programmen gab es bisher keine Probleme, da offensichtlich das Schließen der Datei und das erneute Öffnen jeweils mit Suche nach eindeutiger ID viele Probleme beseitigt.
Sicherlich wäre es die bessere Lösung, wenn man sich auf das OS verlassen könnte, wie es bisher (Citrix auf Windows Server 2003) der Fall war.

ABER DIESE HOFFNUNG NÜTZT MIR NIX !

Die viel beschworene ADS kommt bei uns nicht in Frage und ein SQL Server ist zu teuer (das liegt aber an den Verträgen mit unserem Dienstleister).

@ Jimmy,

wenn du andeuten willst, dass ich nicht weiß wovon ich schreibe, danke für die Blumen ;-)

COMMIT hat nach meiner Erfahrung noch nie geholfen !
Erst mit UNLOCK werden die replace Daten wirklich geschrieben (Info von Alaska, wo weiß ich nicht mehr)
und der folgende DbGoTop() ersetzt den bisherigen DbSkip(0), der bisher reichte, jetzt aber nicht mehr (diese Info habe ich gelesen und kann es nur bestätigen).
Seit ich das eingebaut habe ist wieder Ruhe hier, mehr interessiert mich nicht.

Die massigen Ausführungen zu Servern, IP-Ports, Einstellungen etc. nützten mir nix, ich habe weder die Berechtigung noch die Möglichkeit irgendetwas auf dem Server oder im Netz nachzusehen dass ich die Richtung geht.

@ TOM,

bei einer DBF die im Zugriff ist, ist die RECNO der einzige eindeutige Schlüssel, der immer den bisherigen Satz findet, egal was zwischenzeitlich passiert ist.
Filter nutze ich nicht, und wer eine bessere Lösung hat, soll sie nutzen.

Massive Satzbewegungen (go top, go bottom oder dbgoto(0) dürfte egal sein, wahrscheinlich reicht auch ein einfaches skip) führen dazu, dass die Daten neu von der Platte des Servers geladen werden. Das zeigen die sofort aktuellen Daten auf allen Clients. Bisher reichte dazu das dbSkip(0), jetzt wurde dies wohl "weg optimiert".
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

hi Hubert,

dein Source hat nichts mit "dem" SMB Problem zu tun da dein Code "auf sich selbst" arbeitet und da "sollte" es nicht zu Problem kommen.
dein Source "kümmert" sich um "seine" Daten und wenn du die zurück schreibst dann wird "application-driven caching" geleert. ( was mit COMMIT passieren sollte )

wie ich ausführte entsteht "das" SMB Problem wenn die 2nd Workstation dazu kommt und die DBF öffnet.
die 1st Workstation muss nun vom "exclusive OpLock" auf "Level 2 OpLocks" umschalten
... egal was die 1st Workstation nun macht. "das" ist nun das "OS driven caching" und "hier" entsteht das Problem.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von brandelh »

COMMIT mag schreiben, aber jedes Programm muss die jetzt aktuellen Daten des Server wissen und die bekommt es mit commit nicht.
Die Satzbewegung zwingt das OS und die Runtime dazu die aktuellen Daten einzulesen.

Ich kann euch voll zustimmen, dass die ganze Sch.... so gar nicht sein dürfte, denn
1. dürfte das OS eine gesharte Datei nie auf clients cachen !
2. hätte Alaska schon längst eine optimierte Version OHNE ALTLASTEN bauen können, die solche Probleme nicht hat und Indexfehler erkennt.

Das nützt aber nix. Und warum auch immer, seit der Umstellung auf die neue Version (mit obigen Änderungen) läuft die Anwendung wieder stabil :D
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Datenverlust unter Windows 7

Beitrag von AUGE_OHR »

hi,

ok ... die Bemerkung mit COMMIT war zu kurz.

da er meint ( dein Kollege ) dass er nach einem SKIP(0) "nichts sieht" lässt mich vermuten das ein "Cache" aktive ist.

ich gehe nun davon aus das er sich dabei im SMB1 "exclusive" Modus befand und dann wäre der "Application-driven Cache" ja noch aktive. in "diesem" Fall benötigt man ein COMMIT

bei SMB1 "Ops Level2" ist ja nun der "Application-driven Cache" abgeschaltet(!) deshalb benötigt man kein COMMIT.
gruss by OHR
Jimmy
Daniel

Re: Datenverlust unter Windows 7

Beitrag von Daniel »

brandelh hat geschrieben:Ich kann euch voll zustimmen, dass die ganze Sch.... so gar nicht sein dürfte, denn
1. dürfte das OS eine gesharte Datei nie auf clients cachen !
2. hätte Alaska schon längst eine optimierte Version OHNE ALTLASTEN bauen können, die solche Probleme nicht hat und Indexfehler erkennt.
Ja, es kann nicht sein, dass ich als Applikationsentwickler nicht weiss, ob ich in einem Netzwerk Daten verliere, oder ob ich dem Anwender die richtigen Daten anzeige. So kann man ja nicht arbeiten. Als Applikationsentwickler sollte ich ein Entwicklungssystem haben, das diese Dinge mit dem OS abstimmt und absichert.
Schon ein SKIP(0) ist ja logisch gesehen ein Quatsch, entweder ich mach einen Schritt, oder bleib stehn.
Anderseits hat Steffen P. selber gesagt, COMMIT sei nicht nötig, da er bei UNLOCK resp. DbRUnlock() vom XBase++ automatisch ausgeführt werde.
Es kann doch nicht sein, dass jeder hier in M$-Tech-Doku herumsuchen und seine eigenen Workarounds zusammenbasteln muss :roll: - die dann möglicherweise, wie Tom und Jimmy anmerken, das Problem nicht nachhaltig lösen.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Datenverlust unter Windows 7

Beitrag von brandelh »

dbskip(0) habe ich schon unter Clipper genutzt, dieses explizite Anfordern des Datensatzes,
hat bisher gereicht um Änderungen anderer PCs auf dem Datensatz zu bemerken.
Gruß
Hubert
Antworten