Inoffizielles deutsches Xbase-Forum

hallo!
wir beobachten in letzter zeit ein phänomen, welches wir schon vor einigen jahren in zusammenhang mit dem smb2 workstation cache erlebten: bei zugriff auf ein netzwerkshare kann es passieren, dass im ersten schritt der recordzähler im header auf eine unglaublich hohe zahl gestellt wird und im zweiten schritt dann - bei dem versuch den letzten datensatz anzusteuern - eine 4gb große dbf-datei erzeugt wird.
dieses mysteriöse verhalten tritt nun - anscheinend in zusammenhang mit win10 fallweise wieder auf: wenn das netzwerkshare auf einem win10 rechner liegt und von einem anderen rechner auf dieses zugegriffen wird, kann dieser fehler auftreten (zumeist zur zeit, wenn win10-updates bereitgestellt werden). wir verwenden hier die foxdbe.
kennt ihr ähnliches? ideen?
lg
ernst

ecz hat geschrieben: ↑Mi, 07. Nov 2018 22:24 bei dem versuch den letzten datensatz anzusteuern - eine 4gb große dbf-datei erzeugt wird.

hm ... ist mir noch nie passiert

wie sieht denn deine DBESYS aus
welche Xbase++ Version

Hallo Ernst,

da stimme ich Jimmy zu - noch nie gesehen sowas. Und ich arbeite fast ausschließlich mit FOXCDX, und sehr viel in Netwerken.

Neben den von Jimmy angefragten dbesys und Xbase++-Version: Was für ein Server? Welches Windows auf den Clients? Wie die Laufwerke freigegeben und angebunden?

Mal eben eine 4 GB-Datei zu schreiben geht ja auch nicht von jetzt auf gleich. Das muß dann doch auch irre Verzögerungen geben, oder?

Jan

weder mit foxdbe noch dbfdbe konnte ich eine DBF mit mehr als 2,4 GB erstellen bzw. beschreiben.
Es muss sich um eine andere DBE handeln !

Ich habe das bisher 3x in den letzten Jahren erlebt, das einige geöffnete Datenbanken auf eine Größe von 2,quitsch GB anwuchsen und dadurch mein Programm zum Absturz brachten.
Aber größer als 2,quitsch wurden diese nie.

Sind die angehängten Sätze dann leer? Oder ist die dbf defekt?

Jan

Bei mir waren sie defekt, d.h. sie ließen sich nicht mehr öffnen.

bezüglich xbase-version: jeweils eine ziemlich aktuelle 2.0
bezüglich dbesys(): das muss ich mir anschauen, habe mich damit noch nicht auseinandergesetzt - diese hat der kollege mit dem ich zusammenarbeite erstellt.
zu den 4gb-dbf:

• die größen variieren leicht, erreichen aber immer die 4gb: z.b. 4.294.967.265 -. die letzten drei zahlen können differieren - hat nach meiner ansicht mit dem jeweiligen header zu tun (273 - 464 - 400 - 328 etc.)

• die dateien lassen sich in der regel aufmachen (nur z.b. bei einem dbgobottom() kann es schnell zu einem absturz kommen, habe aber auch dateien erlebt, wo der header teilweise überschrieben war. ich habe mittlerweile mir schon ein reparaturtool gebaut, welches auch einen defekten header austauscht, bzw. wenn nur der eintrag für die recordanzahl falsch ist, diese neu errechnet und die datei in korrekter größe neu schreibt.

• zumeist sind die überschüssigen records reiner mist - und daran kann ich erkennen, wo eigentlich das dateiende wäre. letzte woche habe ich aber erstmals eine datei erhalten, bei der alle records bis zur 4gb-grenze mit dem inhalt des record 1 geschrieben waren... da müßte ich noch nachprüfen, ob es hier in der programmlogik überhaupt einen anderen grund geben kann - ich kann mir aber trotzdem vorstellen, dass das problem mit einem irrwitzigen recordeintrag im header startet

• das ganze tritt pro monat in ca. 0,25 - 1% der regelmäßig genutzten anwendungen auf. so wie es aussieht nur in netzwerkumgebungen auf, wo zwei geräte auf eine dbf auf einem netzwerkshare zugreifen. das share liegt dann anscheinend immer auf einem win10-rechner. das problem tritt möglicherweis nur dann auf, wenn anscheinend win10 versucht updates zu verarbeiten

danke für eure rückmeldungen!
ernst

ecz hat geschrieben: ↑Do, 08. Nov 2018 16:33 das share liegt dann anscheinend immer auf einem win10-rechner. das problem tritt möglicherweis nur dann auf, wenn anscheinend win10 versucht updates zu verarbeiten[/list]

Dann wäre die Lösung ja einfach, indem die Einstellungen für die Windowsupdates so geändert werden, dass während der Arbeitszeiten keine Updates durchgeführt, oder noch besser, die automatischen Updates abgestellt werden.

Hallo Ernst !

das problem tritt möglicherweis nur dann auf, wenn anscheinend win10 versucht updates zu verarbeiten

Das heißt was genau?

Wenn das Windows-Update für einen Neustart des PCs dein Xbase++-Programm "abschießen" muss, solltest du daran Hand anlegen.

Du mußt einen Handler einbauen, der auf die "WM_CLOSE"-Nachricht von Windows ein sicheres Herunterfahren deiner Applikation auslöst. Also alle Tabellen schließen und Programm beenden.

zu euren überlegungen:

1. der rechner wird nicht neu gestartet und das programm abgeschossen, sondern "plötzlich" entstehen 4GB dateien. die beobachtung ist, dass dies immer dann passiert, wenn gerade updatezeit ist.
2. ja, die updates würden wir gerne verhindern. da wir aber für die hardware und die installation nicht immer zuständig sind, gibt es alles mögliche. und auch wenn wir anraten updates in der beschriebenen weise zu konfigurieren, so wird dies sicher nicht durchgängig so gemacht und wenn ein problem auftritt der fehler sowieso uns zugeschrieben...