XProfan

Italia

Falk
Fallenstein

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

Ich habe circa 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 per den dBase-Interpreter (PRG File) 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-Testata der Byte-Wert per "year of last update" um 100(dez) bzw. 64(hex) aumento worden und die File lässt sich mit DOS-dBase nicht mehr öffnen: bei Werten circa 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 per 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-File 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), per alle Befehle und Funktionen, die zum Zurückschreiben oder Schließen einer DBF-File führen, eine Option anzubieten, die die Y2K-Korrektur kontrolliert - z.B. mit einer Funktion db("Y2K", N) mit N=0 per "nein" und N=1(default) per "ja".

Im übrigen möchte ich zum Ausdruck bringen, dass ich die Idee, dBase III als Grundlage per die Datenbank-Programmazione mit Profan auch per die neuen Versionen beizubehalten, per außerordentlich klug halte. Viele Aufgaben, insbesondere per Verknüfungen mehrerer dBase-Tabellen mit unterschiedlichen Strukturen, die ich früher erst durch Export in sequentielle File (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 Citazione Zeilenweise Citazione

Herzlich Benvenuto Falk!

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

27.09.2009 ▲

Vollständiges Zitat

Absatzweise Citazione Zeilenweise Citazione

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 corsa werden.
Kompilieren Markieren Separieren

proc saveY2K

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

en

/a>

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 per 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 per 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 grande 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 Cambiamento 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 Citazione Zeilenweise Citazione