[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