none
Datei mehr als 10 sek. noch geöffnet nach USE IN SELECT(aliasname)

    Frage

  • guten... WasAuchImmerFürTagesZeit du hast....

    Eigentlich kein FOX-Problem, aber da habe ich es festgestellt. Bislang, unter XP-Rechnern nie aufgetreten, habe es erst seit ich zwei PC's auf Windows 7 umgestellt habe.

    Meine Frage ist, An welcher Schraube muss ich herumdrehen, dass W7 mir diese Date scheller zumacht. Bzw, was ich ggf. am Code (s.U) weg oder dazuoptimieren kann.

    (Info) Insgesamt hab ich mehrere PC's miteinander verbunden, die alle auf einen dieser Rechner zugreifen. Daher kann es vorkommen, dass an mehreren Plätzen gleichzeitig eine Datensatz-Neuanlage eingegeben wird.

    Nun passiert das, wenn ich unter W7 eine Tabelle auf einem anderen PC öffne, diese nach dem schließen mehr als 10 Sek. immer noch als offen am Zielrechner gemeldet wird. (lt. Übersicht der Computerverwaltung->Geöffnete Dateien)

    Der Zugriff erfolgt wie hier abgebildet

    && Ticket-Daten vorbereiten und in ein Objekt packen ....

    && Neues Ticket erstellen
    IF !EMPTY(ADIR(DummyArray,(.DisTable))
    FOR Lc_I = 1 to 3

    TRY
    USE (.DisTable) ALIAS (.DisName) in SELECT(.DisName) EXCLUSIVE
    CATCH
    ENDTRY

    IF USED(.DisName)
    EXIT
    ENDIF
    WAIT "Ticket wird angelegt" WINDOW TIMEOUT 2 NOCLEAR
    ENDFOR
    WAIT CLEAR ENDIF

    IF !USED(.DisName) && bin gerade mal Offline??
    = SaveOffline(Lc_Ergebnis) && Ticket wird über Timer-Polling
    RETUEN .f. && paar sekunden später gespeichert
    ENDIF

    SELECT(.DisName) SET ORDER TO TICK IN (.DisName) GO BOTT IN (.DisName) SCATTER FIELDS DisTicket NAME Lc_Ergebnis ADDITIVE Lc_Ergebnis.DisTicket = Lc_Ergebnis.DisTicket + 1

    && Datenrecycling, ältesten gelöschten/freigegebenen Satz verwenden SET ORDER TO RECY IN (.DisName) GO TOP IN (.DisName) IF EOF(.DisName) APPEND BLANK ENDIF GATHER NAME Lc_Ergebnis MEMO ** Wegen W7 eingefügt, da verzögtertes schreiben FLUSH IN (.DisName) FORCE USE IN SELECT(.DisName)

    Wenn unter XP (früher W2k) die letzte Zeile bearbeitet wird, dann wird am Zielrechner (auch XP-PC) diese auch SOFORT geschlossen. Wird diese aber unter W7 ausgeführt, dann dauert das so irgendwas zwischen 10-15 Sekunden, bis die zu ist.
    Dadurch hatte ich bislang noch keine Kollision von wegen FILE IN USE, wenn innerhalb dieser kurzen Zeit eine andere Anwendung bzw. ein anderer PC auf diese Datei zugreifen wollte.

    Diese Datei wird u.A. so alle 5-10 Sek. von jedem Arbeitsplatz auf Änderung geprüft.
       =FDATE(.DisTable,1)
    und bei Änderung mit NOUPDATE zum einlesen der neuen Daten kurz geöffnet.
    Aufgefallen ist mir das schon vorher, denn die Aktualisierung der anderen Übersichten (die aus dieser Tabelle ausgelesen werden) zwischen 10 und 30 Sek. verzögert angezeigt werden. daher das FLUSH. 

    && Übersicht aktualisieren. 
    && Wird über Timer alle paar Sek. aufgerufen
       Lc_DisTime = FDATE(.DisTable,1)
       IF Lc_DisTime == .LastDisRead
          RETURN .t.
       ENDIF
    
       TRY
          USE (.DisTable) ALIAS (.DisName) IN SELECT(.DisName) NOUPDATE
       CATCH
       ENDTRY
    
       IF !USED(.DisName)
          RETURN .f.
       ENDIF
    
    && Neue und geänderte Daten einlesen
       SELECT * FROM (.DisName) ;
          INTO CURSOR (.DisTemp) READWRITE ;
          WHERE TimStmp >= .LastDisRead
       USE IN SELECT(.DisName)
       .LastDisRead = Lc_DisTime
    
    && Übersicht aktualisieren
    ....


    Ps: ein AutoIncrement auf das Feld geht nicht, denn diese Nummer kann öfters vorkommen


    Samstag, 12. Mai 2018 23:40

Alle Antworten

  • Mal abgesehen von Details, Ist Dein zentrales Problem nur die Verzögerung in " Computerverwaltung->Geöffnete Dateien", oder hast Du auch für 10-15 Sekunden keinen Exklusivzugriff auf anderen Rechnern?
    Wie wäre es mit DOEVENTS FORCE nach dem FLUSH? Oder nach dem Schließen? Oder beidem? DasFilesystem muß auch die Chance haben aktiv zu werden.

    Dann scheint mir die Art von Synchronisation eine Datenreplikation zu sein,ich weiß nicht, ob das die beste Idee ist, Du hämmerst dann ja sowieso von vielen Seiten auf einer Datei rum. Wenn Du schon sowas machst, dann schreib in eine extra dbf alle Änderungen, die für alle anderen Clients abzuholen sind, evtl sowas wie Tabellenname_sync_datumzeit.dbf, die ist dann jeweils nur mit neu zu synchronisierendem befüllt, d.h. das polling beschränkt sich auf ein ADIR mit entsprechendem Filesekelton. Nach abarbeitung gehen diese Dateien dann per ERASE weg.

    Tschlüß, Olaf.


    Olaf Doschke - https://www.doschke.name

    Montag, 14. Mai 2018 04:22
  • hey olaf;

    danke für die rasche Antwort.

    Nach dem schließen (USE IN SELECT...) passiert nur noch maximal ein ThisForm.Release() und die Anwendung wartet auf das nächste Event.

    Aber ich teste das mal mit DOEVENTS / DOEVENTS FORCE aus.

    Das mit der externen sync-Datei hab ich mir schon mal überlegt. aber das Problem besteht darin, dass auch Offline (Laptop) Tickets angelegt/bearbeitet werden. Die werden die Neuanlagen Lokal mal gepuffert (ohne Tk-Nummer) und wenn dieser Läppie wieder Online, also im Netz angemeldet ist, eingetragen. Der wird dann auch mit den anderen neuen synchronisiert.

    Btw. Beendet markierte Tickets werden ausgelagert und dann nach 14 Tagen automatisch gelöscht.

    lg mike

    Montag, 14. Mai 2018 12:05
  • Ich frage mich nur, ob die Aussage von Computerverwaltung->Geöffnete Dateien irrelevant ist.

    Wenn Du die Datei sofort wieder öffnen kannst, kann ja egal sein, dass die Computerverwaltung da hinterherhinkt.

    PS: Es mag sein, dass tatsächlich das OS seit Win7 Dateihandles länger offen läßt, bevor es sie endgültig schließt, als eine von vielen Performanceoptimierungen a la oplocks, die uns FoxProler ja so stören.

    Was oft als scheiternd berichtet wird sind Aktionen wie USE (schließen der DBF, die shared offen ist/war), um direkt danach ein PACK (exklusiv neu geöffnet)  zu machen,

    Was aber auch die Datei sofort "in Angriff" nehmen kann ist Antivirus. Dagegen würde helfen entweder das DBF Dateiformat oder das Datenverzeichnis von Virenscans auszuschließen, das ist auf jeden Fall auch eine Mögliche Ursache.

    AV kann sich über Filesystem Filter so tief reinhängen, dass es noch vor allem anderen den Exklusivzugriff auf geänderte Dateien "beantragen" kann. Gleich ins Eingemachte geht die Liste von Minifilter "altitudes", da findest Du alle namhaften AV Software Hersteller und Produktnamen wieder: https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes

    Such z.B. nach Kaspersky oder Bitdefender.

    Die Bedeutung dieser "Altitudes" (Höhen) im Minifilter System ist nicht mal so nebenbei erklärt, aber sagen wir einfach mal da sind Hooks am werkeln. Wenn's das ist, dann ist das einzige, um zu verhindern, dass AV jeder Änderung nachhakt, AV eben per Konfiguration da rauszuhalten.

    Tschüß, Olaf.


    Olaf Doschke - https://www.doschke.name


    Montag, 14. Mai 2018 15:15
  • du meintest:

       Ich frage mich nur, ob die Aussage von Computerverwaltung->Geöffnete Dateien irrelevant ist.

    Wie sehr man sich auf die "Computerverwaltung" unter XP verlassenkann, weis ich nicht. Jedoch wenn ich den eingangs erwähnten Ablauf auf einem XP-PC audführe, mit Daten auf einem anderen XP-PC, dann sehe ich beim Refresh (F5) der Übersicht, dass die Datei quasi sofort ausgetragen wird. Ist hingegen ein W7 mit der Speicherung auf dem XP-PC, dann bleibt die Datei echt etwas länger offen. (nach ca 15 mal F5 drügge iss se wech)

    Du meintest
        Wenn Du die Datei sofort wieder öffnen kannst, kann ja egal sein, dass die Computerverwaltung da hinterherhinkt.

    Im eigenen Programm, also "USE...EXCL -/- TuWasMitDaten -/- USE...SHARED" mach. dann hab ich keine Probleme. Auch wenn ich einige Millisekunden später von einem dritten PC darauf zugreife geht das in Ordnung.
    Ohne dem umswitchen auf USE SHARED, bleibt die Datei als EXCLUSIVE die o.A. Zeit offen und ich flieg mit dem dritten PC auf die Nase.

    Wie gesagt. Dieser Programmteil lief seit etwa 2006/2007 im XP-Netwerk ohne grösseren Kollisionen. Erst unter W7 bin ich öfters aus der "FOR Lc_I"-Schleife ohne öffnen der Datei rausgekommen.

    Der User merkt zwar kaum die Auswirkung, ausgenommen er hat die Übersicht der offenen Tickets auf dem Bildschirm mitlaufen. Dann fällt es eben auf, dass wenn er ein Ticket anlegt, welches normalerweise maximal nach 10 Sek Sichtbar wird, dann doch bis zu 30 oder mehr Sekunden braucht.

    Ein PACK läuft im Normalbetrieb nur an Sonntagen unmittelbar nach 0:00h. Da wird ii.d.R. keiner am PC-hocken. Da werden erst mal die abgeschlossene Tickets in das Archiv verschoben und als Archiviert markiert Die bleiben aber noch 4 Wochen fürs Datenrecycling in der Tabelle stehen. Dann werden die physisch entfernt und per Pack entsorgt

    Antivirus verwenden wir den AVIRA und die Datenverzeichnisse sind dort in der Whitelist eingetragen.

    lg mike:

    Als Info:
    Erfassung/Bearbeitung und Übersicht sind getrennte Programme (wegen der Offline-Bearbeitung), wobei in der Übersicht auch die Bearbeitung inkludiert ist. Die Übersicht läuft im Hintergrund und ist in der SysTray abgelegt/versteckt. 
    Daher ist es auch nur aufgefallen, wenn die Neuanlage außerhalb vom Übersichtsproggie eingegeben wurde.

    Im eigenen Proggie kann ich ja eine EXCL geöffnete Tabelle ja nochmals öffnen

    USE (MyTable) ALIAS (Srcname) IN SELECT(SrcName) EXCLUSIVE
    
    USE (MyTable) ALIAS (RefName) IN SELECT(RefName) SHARED AGAIN
    
    dann ist die ja zweimal offen, aber in beiden fällen EXCLUSIVE. Das SHARED wird in diesem Fall sogar vom Fux ohne Fehler ignoriert. (Siehe Bild auf http://asia-da.de/ScriinSchuut/Frm_164.jpg)
    Ein weiteres EXCLUSIVE erzeugt die Fehlermeldung.

    Mittwoch, 16. Mai 2018 13:46