Inoffizielles deutsches Xbase-Forum

Hallo,

bei uns steht der Upgrade von Windows Server 2008 auf 2016 bevor.
Ich kann mich gut an das Drama erinnern, bis der 2008 endlich die Xbase SMB2 Fix Installation akzeptiert hat (einer der FileInfo... Caches hat den 0 Wert verweigert).
Außerdem finden die Server Verwalter so altmodischen Kram immer suspekt, schließlich war das ja zur Performanceverbesserung eingeführt worden

Ich habe 5 DBF Dateien mit 1 bis 3 NTX Dateien, ohne den richtigen Eintrag waren die Indexe mehrmals am Tag futsch.

Allerdings ist es in dem Programm eigentlich so, dass es immer ein Aktenzeichen gibt, das der Sachbearbeiter kennt bevor er den Fall aufmacht.
Weiterhin ist es so, dass alle Daten älter als x Jahre regelmäßig gelöscht werden müssen ...

Nun hatte ich schon mal mit dem Gedanken gespielt, dass ich je Akte (also Versicherter) eine Datei anlege, die alle Daten enthält.
Ein Xbase++ Objekt, liest die Datei ein und füllt seine Strukturen (das Objekt würde ich durchaus aus einer fixen Klasse bauen) automatisch,
die Bearbeitung findet statt und die Daten werden gespeichert.
Der XML Parser scheint mir da eher umständlich.

Früher hätte ich da an INI API Funktionen gedacht und wegen der Umstellungsmühe wieder verworfen.
Auch die Dateien mit Variablen speichern etc. gehen gar nicht (mag ich nicht).

Aber nun gibt es ja XML Dateien und neue Funktionen in der 2.0, aber ich sehe noch nicht ob das damit geht was ich mir gedacht habe.
Hat jemand Erfahrungen damit ein Objekt einer Klasse mit einem Befehl auf die Platte zu schreiben ?

Wie ist das dann mit dem Sperren, das geht doch sicher nicht oder ?
Wie weiß z.B. Word, dass eine Datei in Bearbeitung ist ?

Hallo Hubert,

MS-Office-Programme legen beim Öffnen eine temporäre Datei mit dem Dateinamen und einem "~$" davor an. Damit erkennen andere Instanzen des Programmes beim Öffnen der Datei, daß das nicht noch einmal geöffnet werden sollte.

Ansonsten: Ich arbeite viel mit JSON. Xbase++ hat da ganz tolle Funktionen drin, mit denen man einen JSON-Text-String in ein DataObject wandeln kann und wieder zurück. Die DataObjects Browse, editiere, etc. ich dann. Mit XML ist das etwas komplizierter, weil die DataObjecte da anders strukturiert sind.

Jan

Würde das reichen ?

oAkte := Json2Var( cJson ) // Datein aus Datei in Objekt
cJson := Var2Json( oAkte ) // Objekt Daten in Datei schreiben

und wofür braucht man dann ...

JsonDecode()
JsonEncode()

und wie erkennt man dass z.B. jemand an der cJson Datei gefummelt hat und der Inhalt nicht mehr stimmt ?

Hallo Hubert,

mit JsonDecode() und JsonEncode() habe ich bislang noch nicht gearbeitet/arbeiten müssen. Alles was ich brauchte ging absolut einwandfrei und geschmeidig auch so. Ich denke mal das müsste bei Dir auch gehen. Wenn Du ein DataObject erstellst und füllst, und dann als Json-String speicherst, dann macht Json2var() alles was Du brauchst. Und selbst wenn Du einen Json-String manuell erstellst klappt das in den Fällen, die ich bislang hatte, auch.

Wie Du unbefugte Änderungen kontrollierst? Du legst eine Kopie der Datei an einen komplett anderen Speicherort. Und vergleichst die beim Öffnen auf Unterschiede. Nein, im Ernst, dafür gibt es vermutlich keine saubere Lösung. Außer Du speicherst Dir den Hash des Strings mit. Was ja machbar wäre als ein Node des Json-Objektes.

Jan

Wenn ich versuche eine Excel Tabelle mit FOPEN zu öffnen schlägt es fehl, wenn ich diese in Excel geöffnet habe

Hallo Hubert,

kurze Info aus meiner Erfahrung. Ich verwende Xbase V. 1.90.355 mit NTX.
Die DBF liegen auf einem Server 2012 R2 und werden über UNC-Path angesprochen.
Auf den Arbeitspläten Windows 10 und eventuell Windows 7 habe ich den SMB2-Patch eingespielt:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters
DirectoryCacheLifetime
FileNotFoundCacheLifetime
FileInfoCacheLifetime

Diese 3 Einträge müssen jeweils auf Null gesetzt werden.

Am Server gibt es diesen Patch bei mir nicht, da nach meinem Verständnis sich dieser Patch nur auf die Workstation bezieht.
Wenn du also mich fragst, gibt es keinen Grund, daß du deine Software auf einen anderen Zugriff umstellst.

Viele Grüße aus Regensburg
Günter

Hallo Günter,

du hast Recht, dass der Patch auf der Workstation eingespielt werden muss.

Bei einem Citrix-Server läuft die Anwendung aber genau auf diesem Citrix-Server, daher muss nur dieser den Patch erhalten,
die Citrix Clients zeigen nur noch den Bildinhalt, daher ist das Problem bei mir tatsächlich anders.
Wenn die neuen Citrix Server kommen, muss man dort den Patch einspielen, oder ich stelle von shared DBF auf eine andere Lösung um.

Hallo Hubert,

bei deinem beschriebenen Szenarium hilft mein Hinweis natürlich nichts. Aber bevor du deine Software umschreibst, wäre doch ADS noch eine
Überlegung wert.

Viele Grüße und ein schönes Wochenende
Günter

Nein die ADS war für mich nie eine Wahl, ich würde ja einen MySQL Server bevorzugen,
aber das kann ich nicht entscheiden. Ein SQL Server wäre wohl möglich aber sündhaft teuer.

Das einzige was ich habe ist ein Verzeichnis mit Schreibrecht.

ok,
aber vielleicht würde es die von dir befürchteten Probleme nicht geben, wenn du nach jedem schreibenden Zugriff sofort deine DBF schließt, dir vorher
die Record-ID merkst. Dann wieder öffnest und zum entsprechenden Datensatz zurückwechselst.

brandelh hat geschrieben: ↑Mi, 14. Okt 2020 16:35 Ich habe 5 DBF Dateien mit 1 bis 3 NTX Dateien, ohne den richtigen Eintrag waren die Indexe mehrmals am Tag futsch.

Darf ich mir eine Bemerkung bzw. Frage zu der oftmals angeführten SMB2- Problematik erlauben?
Bis dato hatte ich noch bei keinem Kunden ( und davon gibt es tatsächlich eine ganze Menge ) und vor allem
auch bei Standorten mit mehr als 100 Usern und den unterschiedlichsten Kombinationen von WIN-Versionen
auf den Arbeitsplätzen ( alles durch von XP bis WIn10 ) und den diversen Server-Versionen ( 2003, 2008R2, 2012, 2016 )
irgendwelche Probleme mit Datenverlusten oder korrupten Indexen.
Da sind auch schon mal 30 DBF offen und darunter auch etliche mit 5 NTX.

Mache ich was "falsch" beim Proggen weil ich damit keine Problem habe oder bin ich ein echtes Sonntagskind?
Eines steht jedenfalls fest... an den Arbeitplätzen hat keiner dahingehend rumgeschraubt, an den Servern auch nicht
und es hat auch nichts mit Terminalservern zu tun denn es gibt bei keinen, wie immer gearteten Kombinationen
solche Probleme. ( Anderere manchmal aber schon, nur die sind dann immer hausgemacht *smile* )

Wo liegt denn nun eigentlich das wahre Problem dabei?
Was sollte nicht klappen bzw. was sollte Böses passieren wenn man diesen Patch nicht einspielt?

Danke schon mal vorab!

Ich kann nicht beurteilen, warum du keine Probleme hast, meine fingen mit der Umstellung auf Win Server 2008 (Citrix) bzw. Win 7 auf Netzlaufwerke an.
Das obwohl ich ausschließlich mit UNC Namen arbeite.

viewtopic.php?f=24&t=5528&p=60862&hilit=smb2+fix#p60862

in dem Link gibt es auch Beschreibungen von Microsoft, hier ist die Originalseite von Alaska:

https://www.alaska-software.com/communi ... p#download

Kurz gesagt hat Microsoft bei Win Vista (ich dachte bei Win 7) die Aktualisierung von Metadaten auf einige Sekunden herauf gesetzt.
Somit kann es passieren, dass eine Satzsperre oder eine Änderung nicht erkannt wird und die Indexe nicht mehr mit den Daten übereinstimmen oder auch die Datei korrupt ist.

ACHTUNG auf der Alaska Site steht folgendes:

Wenn Sie Xbase++ 2.0 mit Windows 8/8.1 oder Windows Server 2012 oder höher einsetzen,
dann sind die unten aufgeführten Probleme nicht vorhanden bzw. behoben.
Ihre Anwendungen werden dadurch deutlich stabiler und zuverlässiger bei der Verarbeitung
von gemeinsam benutzen Daten (shared data access).

Alaska Software empfiehlt unbedingt Windows auf die aktuellste Version zu aktualisieren,
damit es nicht zu Datenverlust kommt.

Das Problem scheint also heute gar nicht mehr zu existieren ... das löst natürlich auch alle Probleme

Das muss ich morgen (heute) gleich mal intensiv prüfen.

hi,

von welchem Datum ist die Meldung Link

Hallo Jimmy,
s.o. 2. Link von Hubert.

Wolfgang Ciriack hat geschrieben: ↑Mo, 19. Okt 2020 7:35 s.o. 2. Link von Hubert.

uuuuuuups ... da hab ich nicht drauf geklickt.