Office: TransferText Import Delimited(;) Schema.ini

Hallo, allerseits!

Ich habe ein kleines Problem mit dem Import einer (ziemlich großen) Textdatei in eine Access-Tabelle.

Die Datei ist sowohl mit ; getrennt, wie auch zusätzlich mit festen Spaltenbreiten versehen. Es sind ca. 35.000 Zeilen mit z.Z. jeweils 60 Spalten.

Ich kann die Datei grundsätzlich über "Datei - externe Daten - Importieren..." einlesen und mit entsprechendem Aufwand auch die Spalten so einstellen, daß sie korrekt importiert werden.

Nun muß diese Datei aber automatisch importiert werden. Sie wird täglich aktualisiert und der erste Benutzer am Tag, der ein bestimmtes Formular aufruft, soll dann den Import der Tabelle anschubsen.

Ich habe mir dafür mal eine Testumgebung gebastelt. Auf einem Formular habe ich einen "Import"-Button. Das Ereignis dahinter macht Folgendes:

a) Zuerst wird die Textdatei von einem Netzwerklaufwerk (Schreibschutz) auf ein anderes kopiert.
b) Dann wird eine "Schema.ini" im selben Verzeichnis erzeugt. Dabei sind die Definitionen der einzelnen Spalten im VBA-Code. Ändert sich also was an den Spalten, muß nur der VBA-Code angepaßt werden.
c) Dann soll der Import der Datei erfolgen. Und genau das funktioniert nicht richtig.

Die erzeugte Schema.ini sieht so aus:

Code:

[s510m_mat_report.txt]
Format = Delimited(;)
ColNameHeader = True
MaxScanRows = 0
CharacterSet = ANSI
DateTimeFormat = ddmmyy
DecimalSymbol = ,
NumberDigits = 2
NumberLeadingZeros = True
CurrencySymbol = €
CurrencyPosFormat = 1 €
CurrencyDigits = 2
CurrencyNegFormat = -1 €
CurrencyThousandSymbol = .
CurrencyDecimalSymbol = ,
Col1="PART NUMBER" Char
Col2="PART NAME DE" Char
Col3="DRAWING NUMBER" Char
[...
Col60="INDEX" Double

Und die Zeilen der Import-Datei sehen aus wie: (Im Beispiel nur die Überschrift und eine Zeile)

Code:

PART NUMBER;PART NAME DE;DRAWING NUMBER;SUPPLIER NAME;ABC;GAENG;CLASS SOC;TYPE S/B/E;DKZ;EKZ;LEAD TIME;PART PRICE;TOTAL DEMAND;TOTAL DEMAND 6 MONTHS;TOTAL DEMAND 12 MONTHS;AVERAGE CONSUMPTION SERIES;AVERAGE CONSUMPTION SPARE;MIN ORDER QTY;SAFETY STOCK;MIN INV QTY;MATERIAL ON HAND;TOTAL ON ORDER;QTY OF ORDERS;VALUE OF ORDER QTY;AVG DLY USE 60;SPERRSCHLUESSEL;COSTLOG;REPLACED BY;V/B;OLD PART NO;LEAD TIME CHANGE;FIRST DEMAND;K/R;KENN;WERKSTOFF;TYP1;TYP2;TYP3;PART NAME EN;RES. QTY;TECHNICAL INFO;CAT ID;AI ZCH;WEIGHT;GRENZMENGE;ABRUFMENGE;LB ROSTOCK;GR. TVN;TOTAL DEMAND SPARE;SUPPLIER CODE;SUPPLIER COUNTRY;SUPPLIER STATE;HANDL;DARTS;DARTE;ME;ERS-NR;VAKO;SIGMA;INDEX;      

967084686;O-RING                              ;DIN3771-38,7X3,55N                    ;xxxxxxxxxx        ;C;11112;TL;B;256;264;050;0000004,35;00000015,000;00000015,000;00000015,000;00000001,500;00000005,333;00000100,000;00000000,000;00000022,000;00000050,000;00000000,000;000;000000000,00;0000000,25;0/0-0   ;                ;         ; ;         ;170107;      ;K;     ;83FPM/592-SCHWARZBRAUN          ;M;O;T;O-RING                              ;00000001,000;BEZ.ALT:FPM85(W.W.FPM80)                                    ;1830315 ;  ;000000,001;00000;00000;00000000,000;00001,00;00000014,000;00301029-00;Deutschland                      ;02;E;3;3;1;1.7084-686;01,30;00006,932;24

Rufe ich den Import über die Zeile

Code:

DoCmd.TransferText acImportDelim, mrpf3, mrpz, mrpdpf2, True

auf, kommt die Fehlermeldung, daß die Datei "Schema.ini" (das steht in mrpf3) nicht existiert und der Import demnach nicht möglich ist.

mrpz enthält den Namen der Ziel-Tabelle, mrpdpf2 enthält den kompletten Pfad der zu importierenden Datei. mrpdfp3 würde neben dem Dateinamen "Schema.ini" auch Laufwerk und Pfad beinhalten, funktioniert damit aber auch nicht. In der Fehlermeldung werden die "\" dann sogar ausgemerzt.

Versuche ich es hingegen mit

Code:

DoCmd.TransferText acImportDelim, , mrpz, mrpdpf2, True

erfolgt der Import, aber die Felder der Textdatei sind völlig zerstückelt auf die Felder der Tabelle verteilt.

Was muß ich jetzt machen, um den vermaledeiten Import per Schema.ini nun endlich mal zum Laufen zu kriegen?

Könnte es ein Problem damit geben, daß nicht mit auf Buchstaben gemappten Laufwerken (z.B. "N:") gearbeitet wird, sondern direkt die kanonischen Bezeichnungen (z.B. "juprds03\sp_auswert$") benutzt werden? Das wäre fatal, denn jeder Benutzer kann sich das Laufwerk ja auf einen beliebigen Buchstaben setzen.

Gruß, Michael

 

Also ich bin jetzt schon mal ein ganzes Stück weiter...

Ich habe die Textdatei per VBA in ein CSV-konformeres Format gewandelt. Dabei habe ich alle Texte in " eingefaßt, die überflüssigen Leerzeichen (feste Spaltenbreite) entfernt und das ; in ein , gewandelt.

Außerdem habe ich u.a. die Zeile
TextDelimiter="
mit in die Schema.ini aufgenommen. War etwas haarig, das zu finden. Außerdem waren sich einige Google-Treffer wohl auch nicht einig, ob es nicht eher "TextQualifier" heißen sollte. ;-)

Jetzt kann ich die CSV sauber in Access importieren oder auch als externe Tabelle verknüpfen. Mit dem Zwischenschritt der Konvertierung geht es. Dauert zwar ein bißchen, aber ok.

Excel ist leider nach wie vor der Meinung, den Wert "3/8-1234" in ein Datum wandeln zu müssen, obwohl er in " eingefaßt ist. Aber das ist ein anderes Problem... ;-)

Was ich nur nicht so recht verstehe:

Ich kann jetzt auch die TXT als externe Tabelle verknüpfen, ohne daß sie verhackstückt wird. (Ist mir nur nicht ganz klar, welche Änderung jetzt dafür zuständig war.) Versuche ich aber, sie direkt mit TransferText einzulesen, hab ich wieder nur 27 Felder "Text 255" in der Tabelle und eine 2. Tabelle "Importfehler" mit einem Haufen nichtssagender Einträge.

Jemand da vielleicht eine Idee? Ich brauch die TXT nämlich schon als "interne" Tabelle und würde mir gerne das CSV-Konvertieren sparen. Klar, ich könnte auch die verknüpfte Tabelle per Abfrage in eine interne kopieren. Aber auch diesen (zusätzlichen) Schritt würde ich gerne sparen. Die Tabelle mit deutlich über 30.000 Zeilen braucht ja dann doch immer etwas, bis die aufbereitet ist, gerade wenn das Netzwerk auch nicht unbedingt das Schnellste ist.

Das Einbinden an sich dauert schon recht lange, auch wenn ich MaxScanRows auf 1 oder den Defaultwert 25 runtersetze. Mir war schon klar, daß bei 0 alle Zeilen gescannt werden. Es hat aber den Vorteil des Cachings, wodurch der 2. Durchlauf beschleunigt wird.

Gruß, Michael