Alte dBASE-Versionen mit Windows 10

Nach längerer Zeit mal wieder was Neues, wieder direkt aus der Praxis mit dBASE Plus:

Die Nutzung älterer dBASE-Versionen mit neueren Windows-Varianten, also alles ab Windows 7, Windows 8 und Windows 10 ist mitunter kritisch. Vorallem bei 64 bit Versionen von Windows ist ein Update auf das aktuelle dBASE Plus sehr ratsam. Dies gilt für alle früheren dBASE Versionen der Versionsreihe 2.x und die noch älteren Varianten dBASE 2000 und dBASE Personal. Von Oldtimern wie dBASE for Windows und Visual dBASE (noch 16 bit und aus den 90er Jahren des letzte Jahrhundert) ganz zu schweigen. Und ja, auch die werden bis heute noch eingesetzt.

Diese älteren dBASE Versionen führen besonders bei exklusiven Dateizugriffen gern mal zu sporadischen Fehlern. Sporadisch in dem Sinn, dass es 125x gut gehen kann, bis es dann doch knallt. Betroffen sind vorallem Befehle wie REINDEX, CREATE und nicht zuletzt PACK, also alle Befehle, die einen exklusiven Zugriff auf dbf- und mdx-Dateien durchführen. Mein Eindruck ist auch, dass sich das in den letzten Monaten häuft. Die ständigen Updates neuer Windows-Versionen, auf die man als Benutzer kaum noch Einfluss hat, mögen ihren Anteil daran haben. Doch nicht immer, es gibt auch Benutzer älterer dBASE Versionen mit Windows 7/8/10 ohne Probleme dieser Art.

Ob, wann und wie oft es knallt hängt leider sehr von den jeweiligen Umständen ab. Also davon welche Versionen von dBASE und Windows genutzt wird, welche Rechte der jeweilige Benutzer hat, was sonst noch gleichzeitig auf dem System passiert und und und … Die einzige Gemeinsamkeit ist, dass etwas nicht mehr oder nicht immer funktioniert, das früher (bei früheren Windows-Versionen) nie Probleme machte. Eine andere Lösung ausser dem Update auf eine aktuelle dBASE Version kenne ich leider nicht (ok, Sie könnten natürlich zurück zu Windows XP, dem besten Windows aller Zeiten, aber naja …).

Darum aus eigener leidvoller Erfahrung hier ein Tip, wie Sie solche Probleme vielleicht etwas eindämmen können. Wie gesagt, sie entstehen weil dBASE nach exklusiven Dateizugriffen nicht mehr alle Sperren der Datei zurücknimmt, oder weil die Zurücknahme der Sperren vom System nicht korrekt ausführt wird. Liegt es an dBASE, an Windows, am Dateisystem, am Netzwerk, an der SSD, am Virenscanner, am Wetter, wer weiss das schon. Aber die Schuldfrage bringt eh nicht weiter, es geht zuerst um eine schnelle und pragmatische Lösung, und dann um einen sauberen und langfristig tragfähigen Fix. Letzteres geht nur per Update, für das erste bietet sich etwas an, das ebenso dämlich aussieht wie es tatsächlich helfen kann. Hier mal eine einfache Variante, der genaue Code hängt vom Einzelfall ab. Mir geht es darum das Prinzip zu zeigen, Sie werden es dann in Ihrem Projekt umsetzen können.

USE xyz.dbf exclusive
PACK
SLEEP 0.5
USE
UNLOCK
SLEEP 0.5
UNLOCK 

Zuerst der übliche PACK Befel, wie er seit Jahrzehnten bei dBASE Standard ist, um exklusiv geöffnete Tabellen zu bereinigen und als gelöscht markierte Datensätze endgültig zu entfernen. Dann lässt man dBASE kurz pausieren, erst danach wird die Datei mit USE wieder geschlossen.

Das ist alles fast normal und wie früher, das war schon 1980 mit dBASE II unter MS-DOS so. Fast, denn neu ist die Pause nach dem Packen und noch vor dem Schliessen der Datei, falls das Betriebssystem (nicht dBASE!) noch Daten gepuffert hat. Und ebenfalls neu ist, dass nach dem Schliessen der Datei mit UNLOCK die exklusive Dateisperre erneut aufgehoben wird. Für die sehr seltenen Fälle, in denen das nicht wie sonst automatisch mit dem USE Befehl passiert, warum auch immer.

Das war das Netz, jetzt kommt der doppelte Boden: danach macht ein weiteres SLEEP noch eine kleine Pause und es folgt zur Sicherheit ein weiteres UNLOCK. Ein weiterer Sicherheitspuffer, falls die exklusiv geöffnete Datei weder bei USE noch beim ersten UNLOCK korrekt freigegeben werden konnte. Braucht es das wirklich? Tia, vielleicht in einem von 1.000 Fällen …

Die Pause kann auch verlängert werden, z. B. auf 1 Sekunde oder mehr. Meist dauert das Packen oder das Erstellen neuer Indizes ja sowieso deutlich länger, da kommt es auf eine weitere Sekunde nicht an. Warum die Pause überhaupt nötig ist und hier tatsächlich helfen kann dürfte an der uralten BDE liegen, über die dBASE teils noch immer auf Datenbanken und Tabellen zugreift.

Wie gesagt, das erscheint völlig widersinnig und wer den Code sieht und versteht fasst sich an den Kopf. Aber es kann tatsächlich helfen die schlimmsten Albträume zu mildern, die sich einstellen können bei altem dBASE und neuem Windows. Ich habe das auch nur einfach mal auf Verdacht probiert und zuerst nicht wirklich geglaubt dass es hilft. Aber trotz anfänglichem “du programmierst seit 35 Jahren, du weisst dass das ein ausgemachter Blödsinn ist” habe ich erlebt, dass genau das bei einem konkreten Problem die Lösung war. Für ein Projekt mit dBASE Plus 2.7 von 2011 auf 64 bit Windows 10 im Jahre 2018. Und nachdem der Kunde das Programm über ein Jahr ohne obige “Lösung” ohne nennenswerte Probleme unter Windows 10 betrieb!

Freilich ist sowas nur eine vorübergehende Lösung, solange bis man ein aktuelles dBASE Plus hat, das auch mit den aktuellen Versionen von Windows korrekt arbeitet, und mit dem dann solche Verrenkungen nicht mehr nötig sind. Ein Zeitgewinn, nicht mehr und nicht weniger.

Februar 2018