[Allegro] IMPORT 32bit, release 1, kann getestet werden
Sibylle Koczian
Sibylle.Koczian at t-online.de
Mi Dez 2 16:17:00 CET 2009
Lieber Herr Eversberg, liebe Liste,
Bernhard Eversberg schrieb:
> Das zweite Problem ist kat00.aim. Da steht drin:
>
> #00 IdNr importieren (#00 nicht mehr da nach dem Einlesen!)
> j0
> = "#00" wenn am Anfang aber doch #00 steht, dann 3 Zeichen nach rechts
> } 3 hier 4 bzw. 5, wenn man ein 3- bzw. 4stelliges Schema hat
>
>
> Am 28.3.2002 wurde eingeführt, daß = "#nnn" nicht das Zeichen #
> vergleicht, sondern die Kategorie #nnn sucht und deren Inhalt
> vergleicht. Daher konnte das sowieso nicht mehr klappen. Man
> schreibt da jetzt besser
> = "?00 "
>
Ergebnis meiner ersten Versuche mit der erneuerten nimport.exe: mit
einer korrigierten kat00.aim und auch mit einer Original-mab2.aim läuft
das Programm durch und das Ergebnis sieht vernünftig aus - im Detail
untersucht habe ich es nicht, denn:
Mit einer unkorrigierten kat00.aim und mit meinen abgewandelten
MAB-Importparametern stürzt es nach wie vor ab, ohne eine andere
Fehlermeldung als das bekannte Windows-Meldungsfenster. Die Ausgabedatei
wird zwar erzeugt, ist aber leer. Ich kann also auch nicht eine Stelle
in den Daten dingfest machen, die den Absturz auslöst.
Das heißt einerseits: in meinen Parametern steckt mindestens ein Fehler,
der das alte import.exe nicht weiter gestört und sich auch im Ergebnis
nicht bemerkbar gemacht hat, den das neue nimport.exe aber nicht mehr
verträgt. Den muss ich finden. Kann mir jemand einen Hinweis geben, wo
derartige Fehler am ehesten zu vermuten sind?
Es heißt andererseits aber auch, dass bei nimport.exe noch
Handlungsbedarf besteht. Finde ich wenigstens, denn so eine Reaktion auf
Fehler macht einem die Arbeit wirklich schwer.
Beste Grüße,
Koczian
--
Dr. Sibylle Koczian
Mehr Informationen über die Mailingliste Allegro