XProfan

Deutsch

Falk
Fallenstein

Bin ganz neu hier und bei meinen ersten Gehversuchen mit XProfan auf folgendes Problem gestoßen:

Ich habe über 25 Jahre lang mit dBase II/III gearbeitet, sowohl beruflich als auch privat, allerdings unter MS-DOS bzw. später notgedrungen unter der DOS-Shell in MS-Windows. So bin ich mit der Kommandozeilen-orientierten Bedienung von ase III+ und dem Schreiben von Programmen für den dBase-Interpreter (PRG Dateien) immer noch gut vertraut und möchte das auch weiterhin verwenden können. Wenn ich jedoch eine mit meinem guten alten DOS-dBase (anno 1986) erstellte Tabelle in XProfan öffne, ggf. bearbeitet habe und dann wieder schließe, ist im DBF-Header der Byte-Wert für "year of last update" um 100(dez) bzw. 64(hex) erhöht worden und die Datei lässt sich mit DOS-dBase nicht mehr öffnen: bei Werten über 100(dez) bzw. 64(hex) erscheint eine Fehlermeldung "keine dBase-Datei".

Natürlich läßt sich mit einfachen File-Editoren, notfalls sogar mit dem alten DEBUG aus DOS, das "year of last update"-Byte auf einen für DOS-dBase verträglichen Wert zurücksetzen. Mein Vorschlag wäre, in XProfan auf die "gut gemeinte" Y2K-Korrektur gänzlich zu verzichten, denn die Frage, zu welchem Jahrhundert eine bestimmte dBase-Datei nun wirklich gehört, kann ohnehin nur anhand anderer Kriterien relativ sicher beantwortet werden - geeignet wären die vollständigen Einträge "Datum der letzen Änderung", die alle MS-Dateiysteme schon immer bereitgestellt haben (von FAT12 bis FAT32 und jetzt NTFS). Es wäre auch denkbar (um mit dem schon Eingeführten nicht zu brechen), für alle Befehle und Funktionen, die zum Zurückschreiben oder Schließen einer DBF-Datei führen, eine Option anzubieten, die die Y2K-Korrektur kontrolliert - z.B. mit einer Funktion db("Y2K", N) mit N=0 für "nein" und N=1(default) für "ja".

Im übrigen möchte ich zum Ausdruck bringen, dass ich die Idee, dBase III als Grundlage für die Datenbank-Programmierung mit Profan auch für die neuen Versionen beizubehalten, für außerordentlich klug halte. Viele Aufgaben, insbesondere für Verknüfungen mehrerer dBase-Tabellen mit unterschiedlichen Strukturen, die ich früher erst durch Export in sequentielle Dateien (copy field a,b,c to xyz.txt delimited) und anschließender Verarbeitung mit anderen Programmen (z.B. PowerBasic) realisieren konnte, lassen sich jetzt mit Profan "unter einem Hut" erledigen.

Strategien im Vergleich:
Microsoft: der Computer macht mit Dir, was er will ...
XProfan: der Computer macht, was Du von ihm willst.

XProfan 11, Windows XP (1.5 GByte RAM), XProfEd

27.09.2009 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Herzlich willkommen Falk!

Hast Du eine Idee, wie eine XProfan-Funktion aussehen könnte, die dieses Flag zurücksetzt?

27.09.2009 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Falk
Fallenstein

Also wenn ichs mir recht überlege, wird dieses Problem bei den meisten Profanern wohl eher so selten auftreten, dass sich die Implementierung einer solchen Y2K-Korrektur in den allgemeinen Funktions/Befehls-Umfang von XProfan kaum lohnen würde. Ich habe mir deshalb zwei kurze Prozeduren ausgedacht, die jeweils vor und nach der eigentlichen Bearbeitung einer dBase III-Tabelle ausgeführt werden.
Kompilieren Markieren Separieren

proc saveY2K

    assign #1,DBF$
    openRW #1
    seek #1,1
    YLUpdate%=getByte(#1)
    close #1

endproc

Kompilieren Markieren Separieren

proc restoreY2K

    assign #1,DBF$
    openRW #1
    seek #1,1
    putByte #1,YLUpdate% MOD 100
    close #1

endproc

Kompilieren Markieren Separieren

--- Hauptprogamm -------------------------------------
declare DBF$,YLUpdate% ,... (weitere globale Variablen)
DBF$ = "Test.dbf"
saveY2K   der Wert von YLUpdate% sollte jetzt nicht mehr verändert werden!
db("open",#1,DBF$)
Bearbeitung der Tabelle
db("close",#1)
restoreY2K
end

Aus heutiger Sicht ist es schade, dass dem "year of last update" nur ein Byte spendiert wurde, denn die Unsicherheit für das "richtige" Jahrhundert ist nicht zu beheben. Die Umstellung der Dateistruktur beim Wechsel von dBase II auf dBase III im Jahr 1984 (nach Orson Welles der Beginn des "Big Brother"-Zeitalters) wäre ein geeigneter Zeitpunkt für die Einführung eines eindeutigen Datums gewesen, aber die Leute von AshtonTate haben wohl nicht daran gedacht, dass es auch nach 2000 noch Leute gibt, die mit dBase III gerne arbeiten. Ich erinnere mich, dass eine Menge SysOps deswegen Angst vor der großen Katastrophe beim Jahrtausendwechsel hatten, aber so schlimm ist es ja zum Glück nicht gekommen. Jetzt entfernen wir uns immer weiter von Y2K und die nächsten Probleme würden erst wieder am 1. Januar 2101 zu erwarten sein. Aber bis dahin ist ja noch ein gutes Weilchen Zeit.

P.S.
Ich habe den Eindruck, dass nicht alle Datenbankoperationen zu einer Änderung des "year of last update" führen. Das werde ich vielleicht im Laufe der Zeit genauer herausfinden und dann hier darüber berichten.

Strategien im Vergleich:
Microsoft: der Computer macht mit Dir, was er will ...
XProfan: der Computer macht, was Du von ihm willst.

XProfan 11, Windows XP (1.5 GByte RAM), XProfEd

29.09.2009 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren