[Allegro] Update-Dokumentation

[Thomas Fischer]

Grüße an die Herren Berger und Everberg,

vielen Dank für die nützlichen Hinweise!

>> Die Forderung, in jeder Datei eine Information über ihren Zeichencode
>> unterzubringen, ist nicht umsetzbar ohne Komplikationen hinsichtlich
>> der Rückwärts-Kompatibilität. Den eigenverantwortlichen, korrekten
>> Umgang mit den Codierungen würde dies im Ernstfall auch nicht ersetzen.
> 
> Ich hatte dies einmal fuer Parameterdateien als Forderung gestellt,
> um eine vernuenftige Migration nach UTF-8 hinzubekommen, nicht fuer
> Daten.
> 
> In der Hilfeseite "ac-0" steht zum Zeichensatz uebrigens nur:
> 
> "Wenn man diese Form mit anderer Software aus Fremddaten herstellen kann, kann
> das allegro-System sie einlesen. Die Zeichen müssen DOS-ASCII-Codes sein! "
> 
> Ich interpretiere das einmal so, dass mit "DOS-ASCII-Codes" nicht die Codepage
> CP 850 gemeint ist, die "andere Software aus Fremddaten herstellen kann",
> sondern die interne Codierung der Datenbank.
> 
> D.h. allegro-Windows- oder UTF-8 codierte Dateien duerfen nicht als
> "im Externformat" bezeichnet werden (es sei denn, es entspricht der
> internen Codierung der Datenbank).

Es scheint d doch noch ein gewisser Klärungsbedarf zu bestehen, der wohl auch nicht leicht zu beheben ist, an zu vielen Stellen der Dokumentation wird stillschweigend eine interne Kodierung im Ostwest-Font vorausgesetzt, was auch wiederum nicht mit "DOS-ASCII-Code" identisch ist (wenn ich das mal als "DOS Latin 1", wie es in meinem Texteditor heißt, interpretiere), aber immer mal wieder so genannt wird.
Als unbearbeitet sehe ich noch meine Bemerkung an:

> Unheimlich sind mir Aussagen wie "Wenn die Daten im Windows-Code sind (ANSI), dann vor dem  update  noch den Befehl  set c1  einsetzen (ab V25.5)": unabhängig von der Kodierung der Datenbank? Bei h xset steht, dass "1" default ist, das würde meine Daten mit Sicherheit vermurksen (und set c1 eigentlich überflüssig machen, oder was bedeutet hier "default"?).

Nochmals nachgefragt: heißt "default", dass automatisch angenommen wird, dass die externen Daten in ANSI (= Windows Latin 1) und die Datenbank in Ostwest kodiert sind? Und dass beim Update die Daten entsprechend umkodiert werden, auch wenn ich nicht "set c1" setze und daher explizit "set c2" setzen muss? Und was hat "set c0" beim Update für eine Bedeutung? Bei
h xset
steht nichts dazu, bei
h xxcode=xcode u
steht da als Tip, beim Einlesen von Unicode-Daten per Flex "set c0" an den Anfang des Flex(es? Flexion von Flex??) zu setzen.

Unabhängig davon möchte ich gerne mit dem update.job der Allegro- und nicht der HANS-Distribution arbeiten, gibt es dazu noch Hinweise zu den Unterschieden? Und vielleicht einen Hinweis, wie ich verhindern kann, dass ein Datensatz importiert wird, dessen Primärschlüssel schon mehrfach vorhanden ist? Das müsste sich mit dem Job doch steuern lassen.

Und schließlich ist mir Herrn Bergers Antwort nicht verständlich:

>> 4. Ich möchte die zurückgewiesenen Sätze in einer Datei sammeln, um sie
>> später eventuell nachzubehandeln und/oder partiell zu importieren (das ist mein
>> primärer Grund, es nicht mit A99 zu versuchen).
> 
> so eine Aufteilung sollte man m.E. vor dem Update mit einem vorgelagerten
> Export vornehmen.

Wie ginge das? Zum Hintergrund: Ich habe Dissertationsdaten recht unterschiedlicher Qualität aus unterschiedlichen Quellen, so dass ich nur den Namen der Autorin bzw. des Autors als Primärschlüssel einsetzen kann. Das ist plausibel, weil wenige Menschen zwei Dissertationen (schon gar nicht in einem Fach) schreiben und leider unpräzise, weil verschiedene Menschen manchmal denselben Namen haben…

Mit freundlichen Grüßen
Thomas Fischer