Datenverlust unter Windows 7

[AUGE_OHR]

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.

und das "reicht" IHMO immer noch "wenn" man sich im "Level 2 OpLocks" Zustand befindet.

[brandelh]

Hi,

eben haben wir wieder einen Fall mit defektem Indexeintrag gehabt.
Fazit es ist besser, aber eigentlich nicht haltbar

[AUGE_OHR]

eben haben wir wieder einen Fall mit defektem Indexeintrag gehabt.

in welchem Netzwerk "Umfeld" ? ich meine "was" war zu dem Zeitpunkt "wie" aktive ?

wenn du es auf SMB1 zurück führen willst "müsste" ja "irgendwann" die Situation aufgetreten sein "das"*** es dazu kommen konnte.

Fazit es ist besser, aber eigentlich nicht haltbar

wie ich ja anmerkte beachte deine Function die "soll" Situation aber du sorgst damit nicht dafür das "die"*** Situation nicht eintritt.

*** SMB1 "exclusive OpLock" -> ""Level 2 OpLocks"

[brandelh]

Da die Situation erst mit dem Wechsel auf die Windows (Terminal) Server 2008 eingesetzt hat und mit
Windows (Terminal/Citrix) Server 2003 nicht auftrat, bezweifle ich, dass es ein SMB1 Problem ist.
Und ich habe schon mehrfach geschrieben, dass ich keinen Zugriff auf Interna habe.

[brandelh]

*** SMB1 "exclusive OpLock" -> ""Level 2 OpLocks"

Steffen hat auf der DevCon erwähnt, dass man die Dateien mit einem anderen Programm offenhalten soll (aus dem Gedächtnis).
Wenn also ein Programm die DBF mit NTX öffnet ohne damit zu arbeiten, und nun das eigentliche Arbeitsprogramm die Datei als zweiter, dritter etc. öffnet.

Würde dies das richtige OpLock Verhalten erzwingen ?

[AUGE_OHR]

Steffen hat auf der DevCon erwähnt, dass man die Dateien mit einem anderen Programm offenhalten soll (aus dem Gedächtnis).

"anderen Programm" -> selbes Programm andere Workstation ...

Wenn also ein Programm die DBF mit NTX öffnet ohne damit zu arbeiten, und nun das eigentliche Arbeitsprogramm die Datei als zweiter, dritter etc. öffnet.

ja ... und "wo" steht er ... und welcher Index ist "aktive" ...

Würde dies das richtige OpLock Verhalten erzwingen ?

wenn du alle Punkte bedenkst "sollte" keine andere Workstation mehr in den "exclusive OpLock" kommen können sondern immer gleich "Level 2 OpLocks".

[brandelh]

Jimmy du sprichst in Rätseln ... oder ich bin noch nicht wach

Mein eigentliches Programm habe ich dahingehend geändert, dass es die Dateien nur noch öffnet wenn ein Fall bearbeitet wird.
Nach deiner Beschreibung kommt es also zu Problemen sobald der zweite das Programm öffnet und der erste PC somit "falsch" auf die Umstellung von OpLock reagiert.
Ich habe nun - nachdem ich mich an die Äußerung von Steffen und deinen Ausführungen erinnert habe - eine EXE erstellt, die nur alle DBFs inkl. Indexdateien öffnet und wartet bis sie geschlossen wird. Das ist also nun die erste Arbeitsstation, die zwar die Dateien geshared öffnet, aber NIE schreibt.
Somit dürfte diese NIE Probleme verursachen, sobald ein anderer sich mit dem richtigen Programm (jeweils von verschiedenen Rechnern) anmeldet.

Habe ich das so richtig verstanden ?

Du hast weiter oben noch ausgeführt, dass die "Sperrung mit Offset" das Problem verursachen würde.
Wenn man also z.B. eine SQLite DB nehmen würde, trotz der Warnung vor Fehlern in den Netzwerkprotokollen,
dürfte doch das Problem nicht auftreten oder ?

[AUGE_OHR]

Habe ich das so richtig verstanden ?

im Ansatz ja ... nur was "macht" deine 1st EXE mit den DBF / INDEX ... und wo "steht" er ...
eine 2nd. oder 3th. Workstation wird ja weiterhin "versuchen" sie "exclusive" zu öffnen und damit ggf. die 1st Workstation zum "flush" veranlassen ... was "flush" dann die 1st Workstation ?

Du hast weiter oben noch ausgeführt, dass die "Sperrung mit Offset" das Problem verursachen würde.
Wenn man also z.B. eine SQLite DB nehmen würde, trotz der Warnung vor Fehlern in den Netzwerkprotokollen, dürfte doch das Problem nicht auftreten oder ?

SqLite arbeitet IMHO ebenso wie DBF Dateien "File basierend" und SMB ist nun mal die Art und Weise wie mit solchen Dateien umgegangen wird die ge"share"d werden.

[brandelh]

Habe ich das so richtig verstanden ?

im Ansatz ja ... nur was "macht" deine 1st EXE mit den DBF / INDEX ... und wo "steht" er ...
eine 2nd. oder 3th. Workstation wird ja weiterhin "versuchen" sie "exclusive" zu öffnen ...

wie kommst du denn auf EXCLUSIVE ?

Natürlich wird in einer Netzwerkumgebung SHARED geöffnet.

Sorry, aber die letzten SERVER die ich real gesehen habe waren OS/2 Server, denen trauere ich heute noch nach
Ich selbst habe hier ein / zwei NAS Systeme und je nach Umgebung nur Windows 7 bzw. mit Windows Vista und XP gemischte Client Rechner.
Auf diesen kann ich keines der Probleme provozieren, die ich seit der Umstellung der Terminal Server von 2003 auf 2008 habe.

Auf diese Server habe ich weder Zugriff, noch bekomme ich wirklich Infos.
Die 3 Schalter die seit Server 2008 neu dazu kamen wurden laut Admin gesetzt, ob sie auch auf einem Terminal Server für die Clients aktiv sind, keine Ahnung !
Die beiden OpLocks Einträge wurden NIE gemacht, wobei die Daten auf einem super NAS liegen (schon bisher) und mit den alten Server keine Probleme auftraten.
Da diese wohl aber negative Auswirkungen auf geöffnete Office Dateien haben (sollen), bekäme ich die nie durch.

Mit meiner Anwendung werden zwar pro Jahr Leistungen von 4 Millionen Euro berechnet, aber die Hauptmusik spielt eben in einer anderen Liga.

[Alfred]

Hallo Hubert,

könnten Deine Probleme nicht aus einer anderen Ecke kommen.

Schon mal geprüft ob der 2008 Terminalserver nicht die Verbindung automatisch
nach einer bestimmten Zeit killt. Mein neuer normaler 2008 Server hatte dies un-
angenehme Eigenschaft per default. Diese konnte man nur mit einem Trick ab-
stellen(müsste ich erst wieder raussuchen. Schon wieder alles total verdrängt).

Gruß
Alfred

[Daniel]

Auf diesen [...] kann ich keines der Probleme provozieren, die ich seit der Umstellung der Terminal Server von 2003 auf 2008 habe.
Auf diese Server habe ich weder Zugriff, noch bekomme ich wirklich Infos.
Die 3 Schalter die seit Server 2008 neu dazu kamen wurden laut Admin gesetzt, ob sie auch auf einem Terminal Server für die Clients aktiv sind, keine Ahnung !
Die beiden OpLocks Einträge wurden NIE gemacht, [...]

Das ist doch genau das Problem, dass wir als Applikations-Entwickler oft keinen Zugriff auf die Netzwerk-Server und -Einstellungen haben. Und die Kommunikation gestaltet sich da oft recht schwierig, denn der Netzwerk-Verantwortliche findet, seine Defaultwerte seien schon richtig und M$ optimiert alles für sein Office, auch noch per online-Update.

Und wir basteln da herum, versuchen dies - oder jenes - und haben nichts in der Hand ...
- keine Liste mit zu setzenden Registry-Werten, kein offizielles Dokument von Alaska ...

Und der Kunde ruft an und wirft dir vor "dein Programm arbeitet nicht richtig - wann wird das endlich repariert ??"

[AUGE_OHR]

Das ist doch genau das Problem, dass wir als Applikations-Entwickler oft keinen Zugriff auf die Netzwerk-Server und -Einstellungen haben.

http://technet.microsoft.com/de-de/eval ... 70538.aspx da kann man den "latest" Windows Server 2012 downloaden.
es gibt eine ISO und eine "fertige" VHD Version d.h. du musst unter Win7/8 nur noch das VHD "laden" und kannst loslegen.

Und der Kunde ruft an und wirft dir vor "dein Programm arbeitet nicht richtig - wann wird das endlich repariert ??"

wenn das "Umfeld" nicht stimmt wird jede File basierende Application die selben Problem haben ... deshalb "optimiert" ja M$ "seine" Produkte.
bestes Beispiel war WinWord wo es damals nicht möglich war ein Dokument von 2 Novell Workstationen auf dem NW Server zu öffnen ... bis es einen "Patch" gab ...

es ist also IMHO das beste du stellst dir einen "Xbase" (alle Version) "Server" hin

nun muss es ja kein echter "Server" sein ... heute kann man unter Hyper-V (ex. virtualPC -> XpModus) einen vorkonfigurierten "virtuellen Server" laufen lassen.

Anmerkung zu Xbase ( alle Versionen ) : DBF Dateien waren nie für den Netzwerk oder Internet Einsatz von Ashton Tate gedacht.
erst mit Cl*pper und Novell gab es dann einen "Trick" um ein "lock" zu "simulieren" was ja damals auch recht gut klappte.

dann kam M$ mit WinNT ... und W98se mit P2P ... der Anfang vom Ende ...

[AUGE_OHR]

Habe ich das so richtig verstanden ?

im Ansatz ja ... nur was "macht" deine 1st EXE mit den DBF / INDEX ... und wo "steht" er ...
eine 2nd. oder 3th. Workstation wird ja weiterhin "versuchen" sie "exclusive" zu öffnen ...

wie kommst du denn auf EXCLUSIVE ?
Natürlich wird in einer Netzwerkumgebung SHARED geöffnet.

sorry ich war nicht exakt genug da ich SMB1 "exclusive OpLock" -> "Level 2 OpLocks" meine

Ich selbst habe hier ein / zwei NAS Systeme und je nach Umgebung nur Windows 7 bzw. mit Windows Vista und XP gemischte Client Rechner.
Auf diesen kann ich keines der Probleme provozieren, die ich seit der Umstellung der Terminal Server von 2003 auf 2008 habe.

dann probiere mal Server8 (2012) mit Hyper-V ... man will ja schliesslich nicht nur auf PC beschränkt sein.

***

aber nun zurück zum Ansatz denn wir sind noch nicht "fertig" !

SMB1 "exclusive OpLock" -> "Level 2 OpLocks" Umschaltung wirkt ja nun immer noch und dass was die 1st Workstation im "Cache" hat soll ja nun "geleert" werden ... aber was steht den "drin" ?

ich "vermute" mal "dass" was gerade im Record steht ... "wo" er steht ... und welcher Index "aktive" ist ...
ich "denke" deshalb das ein DbGoTop() nicht so gut wäre. ich wähle lieber den GhostRec mit LastRex()+1 oder GoTo(0)
auch beim Index, die ich alle geöffnet habe, wähle ich DbSetOrder(0) wobei die Indexe ja weiterhin "gepflegt" werden.

das ganze lasse ich nun als Erweiterung meiner "internen" Backup Routine laufen statt das Programm gleich nach dem Re-Index zu beenden.

[brandelh]

Hi,

dbGoTop() muss tatsächlich über den Index ermitteln, welcher Satz der erste ist.
Möglicherweise macht er das nicht sehr effektiv, denn es dauert länger als ich gedacht hätte.

Somit probiere ich mal aus, ob dbGoTo(0) bzw. dbGoTo(0), skip schneller und genauso gut arbeiten.
Bei beiden Befehlen geht es ja darum, die tatsächlichen Daten der Platte für die aktuelle Station neu einzulesen.
Das Schreiben müsste nach Steffens Erklärung (2007 oder 2012 ?) das UNLOCK schon veranlaßt haben.

[Daniel]

wenn du alle Punkte bedenkst "sollte" keine andere Workstation mehr in den "exclusive OpLock" kommen können sondern immer gleich "Level 2 OpLocks".

Das leuchtet so weit ein - auch wenn ich die ganzen Hintergründe noch nicht verstehe (zu diesem Stichwort gibt es mindestens 2 Dutzend Beiträge ...).

Könntest Du dazu ein "Rezept" geben, wie man das erreichen kann, dass immer gleich "Level 2 OpLocks" angewendet wird?

[AUGE_OHR]

Könntest Du dazu ein "Rezept" geben, wie man das erreichen kann, dass immer gleich "Level 2 OpLocks" angewendet wird?

über "was" schreib ich den hier ...

p.s. es ist eine "mögliche" Lösung ... nicht "die" ein-zigste ... hängt vom Xbase Source Code ab ...

[brandelh]

Könntest Du dazu ein "Rezept" geben, wie man das erreichen kann, dass immer gleich "Level 2 OpLocks" angewendet wird?

über "was" schreib ich den hier ...

p.s. es ist eine "mögliche" Lösung ... nicht "die" ein-zigste ... hängt vom Xbase Source Code ab ...

Es fehlt noch die klare Antwort von dir auf die Frage ob es reicht, die Dateien mit Indexdateien auf einer / zwei PCs zu öffnen und offen zu halten,
damit weitere Programme (von anderen Rechnern) nur noch in den passenden OpLock kommen - falls das so überhaupt gesagt werden kann.

[AUGE_OHR]

Es fehlt noch die klare Antwort von dir auf die Frage ob es reicht, die Dateien mit Indexdateien auf einer / zwei PCs zu öffnen und offen zu halten,
damit weitere Programme (von anderen Rechnern) nur noch in den passenden OpLock kommen - falls das so überhaupt gesagt werden kann.

das ist doch der Punkt

aber nun zurück zum Ansatz denn wir sind noch nicht "fertig" !

wo ich dann sagte

ich wähle lieber den GhostRec mit LastRex()+1 oder GoTo(0) auch beim Index, die ich alle geöffnet habe, wähle ich DbSetOrder(0) wobei die Indexe ja weiterhin "gepflegt" werden.

wenn nun eine 2nd Workstation ankommt und nach einem "flush" verlangt dann "sollte" die 1st Workstation in den "Level 2 OpLocks" umschalten und beim "flush" kein Problem auftauchen ... im Ghostrec sind nun mal keine Daten ...

wenn man dann noch den 8999 Fehler bei APPEND, SKIP, GOTO oder Index Fehler hat "müsste" es an was anderem liegen z.b. Timeout ... aber das ist noch ein anderes Thema.

[brandelh]

OK,

das war mir nicht so klar, was du meintest.
Ich stelle mal um

[Daniel]

Ok, danke Jimmy

Wenn ich das jetzt so zusammenfasse, wie ich es verstanden habe:

Ich habe nun [...] eine EXE erstellt, die nur alle DBFs inkl. Indexdateien öffnet und wartet bis sie geschlossen wird. Das ist also nun die erste Arbeitsstation, die zwar die Dateien geshared öffnet, aber NIE schreibt.

Diese öffnet jede DBF mit allen Indizes, aber mit DbSetOrder(0) und geht dann auf den GhostRecord mit LastRec()+1 oder GoTo(0).

Dann lässt man diese Applikation immer laufen, um das "richtige" Verhalten mit "Level2 OpLocks" zu erzwingen, falls eine andere Applikation mit den Daten arbeiten will.
Müsste die auf dem Server laufen per Autostart - falls es sowas für den Server gibt - damit sie immer am Laufen ist?

[brandelh]

Um die Anwendung auf dem Server laufen zu lassen, müsstest du dort einen User angemeldet lassen, oder diese als Service installieren.
Serveranmeldung ist nicht die feine Art, aber sie könnte automatisiert ablaufen und dann in den kennwortgeschützen Bildschirmschoner (den einfachsten den es gibt !) gehen ...
Mit Xbase++ Service Programmen habe ich keine Erfahrung und ob dies das OpLock ändern würde ?
Ich würde lieber diese Anwendung bei jedem Client in den Autostart legen.
Bei mir gibt es übrigens immer eine Datei mit der ich alle Anwendungen zum automatischen Beenden bringe:

AdminSperre.NEIN - im Datenverzeichnis, wenn diese zu .JA umbenannt wird, beenden die Anwendungen innerhalb von 5 Minuten (jeweils mit Warnung jede Minute).

Meine oben genannte Service-App (hier als Beispiel ) natürlich auch.
Nur so kann man z.B. neue EXEs einspielen oder die Indexdateien löschen lassen.

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Inkey.ch"
#include "DBFDBE.CH"
#include "NTXDBE.CH"

procedure main()
   local cPfad := "\\SERVER\FREIGABE\"
   local x, i
   local afiles := { { "UL_STAMM.DBF", "UL_STAMM.NTX" , "UL_STA_A.NTX" },;
                     { "UL_JAHR.DBF" , "UL_JAHR.NTX" },;
                     { "UL_REAL.DBF" , "UL_REAL.NTX" },;
                     { "UL_FIKT.DBF" , "UL_FIKT.NTX" },;
                     { "UL_VOR.DBF"  , "UL_VOR.NTX"  },;
                     { "UL_JAV.DBF"  , "UL_JAV.NTX"  } }

   cls
   ?
   ? "ULWIN Daten offen halten um sauberes OPLOCK Verhalten zu erzwingen"
   ?
   if ! file(cPfad+"UL_STAMM.DBF")
      cPfad := "\\TESTSERVER\FREIGABE\"
      ? "LOKALE Installation: ",cPfad,file(cPfad+"UL_STAMM.DBF")
      if ! file(cPfad+"UL_STAMM.DBF")
         ? chr(7),"Fehler ... "
         inkey(10)
         quit
      endif
   endif

   ? "Dateien mit Index ”ffnen"
   ?
   for x := 1 to len(afiles)
       ? (cPfad+afiles[x,1]),", "
       use (cPfad+afiles[x,1]) NEW SHARED // DBF
       if neterr()
          ? "NETERR() ist aufgetreten, Programm beenden."
          dbcloseall()
          inkey(5)
          quit
       endif
       for i := 2 to len(afiles[x])
          ?? afiles[x,i]," "
          if ! file(cPfad+afiles[x,i])
             ?? " *** INDEX FEHLT, ENDE !"
             inkey(5)
             quit
          endif
          set index to (cPfad+afiles[x,i])
       next
       ?? "OK"
       dbGoto(0)
   next
   do while inkey(1) # K_ESC
      @ 20,3 say " Prüfe auf Adminstop: "+dtoc(date()) + "  " + time()
      if file(cPfad+"AdminSperre.JA")
         ?
         ? chr(7),"Admin Stop erkannt, Ende !"
         exit
      endif
   enddo
   quit
return

[AUGE_OHR]

Dann lässt man diese Applikation immer laufen, um das "richtige" Verhalten mit "Level2 OpLocks" zu erzwingen, falls eine andere Applikation mit den Daten arbeiten will.

ein weiterer Client könnte dann nicht in den SMB "exclusive" Modus kommen und somit beim "umschalten" von "dem" Client auf "Level2 OpLocks" nicht "das" Problem auf "der" Workstation produzieren.
nur die 1st Workstation kann ( und darf ) im SMB "exclusive" Modus gelangen ... es kann nur einen geben ...

Müsste die auf dem Server laufen per Autostart - falls es sowas für den Server gibt - damit sie immer am Laufen ist?

weil du keine Bildschirmausgabe benötigst wäre ein "Dienst" möglich ... kommt darauf an wie du dein "Backup" machst.

ich habe dafür eine "extra" Workstation die sich um die Daten "meiner" Applikationen "kümmert" ... wer weiss was der Kunde macht.
die lief im "Standby" und wurde um 00:01 zwecks "internen" Backup und Reindex "geweckt" und ging dann wieder "schlafen".
jetzt schaltet sich die Applikation ein weiteres mal vor Arbeitsbeginn an und "öffnet" alle DBF / Indexe und "hält" die Verbindung zum Server
( Timeout -> GOTO(0) -> LOCK -> UNLOCK )

[Daniel]

Mit Xbase++ Service Programmen habe ich keine Erfahrung und ob dies das OpLock ändern würde ?
Ich würde lieber diese Anwendung bei jedem Client in den Autostart legen.

Ok, danke, der Server fällt für die Offenhalte-Appl. also besser weg. Danke auch für das Code-Bsp.
Was meinst Du für "XBase++ ServiceProgramme"?

Wenn man die Anwendung bei jedem Client in den Autostart legt, könnte man eleganterweise auch abfragen, ob sie schon läuft, und sie dann nicht nochmal starten. Allerdings könnte sie dann auch vom ersten Client auch wieder beendet werden, und dann fehlen.

Die Lösung von Jimmy mit dem extra PC ist natürlich in diesem Sinne das Optimum.

[brandelh]

Wenn man die Anwendung bei jedem Client in den Autostart legt, könnte man eleganterweise auch abfragen, ob sie schon läuft, und sie dann nicht nochmal starten.

ich ging jetzt von einem normalen Client Rechner aus. Beim Anmelden wird per Autostart das Programm gestartet und gleich in den Hintergrund geschickt.
Je Rechner läuft es also nur einmal. Oder hast du Terminal Server ?

[Daniel]

Je Rechner würde es schon nur einmal laufen, aber es würde ja eigentlich reichen, wenn es auf einem Rechner im Netz läuft.
Wie bei Jimmy, der dafür einen extra Client verwendet.