SQL*Loader mit infile "var "

[kuemmelchen]

Struktur der Tabelle t_regions:

Name..............Null?...........Typ
----------------------- --------------- ------
REGION_ID..... NOT NULL NUMBER
REGION_NAME..................VARCHAR2(25)


Inhalt der Control-Datei:

LOAD DATA
INFILE 'regions_var.txt' "var 2"
BADFILE 'regions_var.bad'
DISCARDFILE 'regions_var.dsc'
APPEND
INTO TABLE t_regions
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(
region_id char(1),
region_name char(25)
)

Inhalt der Daten-Datei regions_var.txt:

141,Deutschland,102,Amerika,

Wird der SQL*Loader mit dieser Datendatei und dieser Kontrolldatei ausgeführt, so werden 2 Datensätze eingefügt. Dies ist das erwartete Ergebnis.

Der SQL*Loader liefert aber einen Fehler:

SQL*Loader-501: Datei (regions_var.txt) kann nicht gelesen werden
SQL*Loader-560: Fehler beim Lesen von Datei
SQL*Loader-509: Systemfehler: Der Vorgang wurde erfolgreich beendet.
SQL*Loader-2026: Der Ladevorgang wurde abgebrochen, weil SQL Loader nicht fortfahren kann.

wenn die Datendatei wie folgt geändert wurde:

141,Deutschland,
102,Amerika,

Auch das Ändern der Datendatei in:

151,Deutschland,
102,Amerika,

liefert einen Fehler:

SQL*Loader-501: Datei (regions_var.txt) kann nicht gelesen werden
SQL*Loader-563: Falsche Lõnge f³r VAR-Datensatz
SQL*Loader-509: Systemfehler: Der Vorgang wurde erfolgreich beendet.
SQL*Loader-2026: Der Ladevorgang wurde abgebrochen, weil SQL Loader nicht fortfahren kann.

Was muss in der Kontrolldatei geändert/ergänzt werden, damit der Ladevorgang ohne Fehler funktioniert?

Verwendet wird Oracle 10.2.0.1.0 bzw. 10.2.0.5.0 unter Windows XP


kuemmelchen

[dbwizard]

region_id char(1),
kuemmelchen

Hi,

Dies ist doch sicher falsch, nicht ? Die ID's in deinem Beispiel sind alle 3 stellig ?


Grüsse

[kuemmelchen]

Die ID's sind einstellig!

INFILE 'regions_var.txt' "var 2":

var 2 bedeutet, dass in den ersten beiden Bytes die Länge des Datensatzes eingetragen ist, also 2 Byte.

Die Angabe: 141,Deutschland, bedeutet:
Der Datensatz hat eine Länge von 14 Zeichen.
1,Deutschland, hat eine Länge von 14 Byte.

kuemmelchen

[jum]

Ich habe Dein Beispiel getestet ORACLE 11g WIN 11.1.0.7.
mit der Datei:

141,Deutschland
102,Amerika
083,Polen

klappt es.
Allerdings dürfen in der Variante scheinbar nur Zeilenumbrüche CR=x0d vorkommen.

[defo]

Vielleicht prüfst Du die Datei mal auf nicht sichtbar/druckbare Zeichen, Unix/DOS Zeilenumbruch (in der2. Variante) und versuchst mal mit
records delimited by '\r\n' o.ä. zu arbeiten.

[kuemmelchen]

Die Kontrolldatei wurde wie folgt geändert:
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\n'

Die Datendatei besitzt nur die beiden Zeilen:
151,Deutschland,
092,Amerika,


Der SQL*Loader liefert mir dann folgenden Fehler:

Commit-Punkt erreicht - Anzahl der logischen Datensätze 2
SQL*Loader-501: Datei (regions_var.txt) kann nicht gelesen werden
SQL*Loader-566: Unvollständiger Datensatz am Ende von Datendatei gefunden
SQL*Loader-2026: Der Ladevorgang wurde abgebrochen, weil SQL Loader nicht fortfahren kann.

Es wird aber nur der erste Datensatz eingefügt.


Wird die Länge bei Amerika mit 10 angegeben, so liefert er mir den Fehler:

SQL*Loader-501: Datei (regions_var.txt) kann nicht gelesen werden
SQL*Loader-563: Falsche Länge für VAR-Datensatz
SQL*Loader-509: Systemfehler: Der Vorgang wurde erfolgreich beendet.
SQL*Loader-2026: Der Ladevorgang wurde abgebrochen, weil SQL Loader nicht fortfahren kann.

Was müsste noch geändert werden?

kuemmelchen

[defo]

SQL*Loader-566: Unvollständiger Datensatz am Ende von Datendatei gefunden
SQL*Loader-2026: Der Ladevorgang wurde abgebrochen, weil SQL Loader nicht fortfahren kann.

Es gab mal einen Bug, der auftrat, wenn am Dateiende ein linefeed fehlte. Das ist aber schon ewig her.
Da er offenbar die erste Zeile frisst, probier als workaround mal ein [CR]/LF oder so am Ende der Datei. Oder füg mal einen 3. Satz ein. Dann müsstest Du ja 2 Sätze importiert bekommen.
Anhand Deines Posts kann man nicht sehen, ob er nun ein CR/LF zuviel hat, also ein 3. Zeile existiert (ohne Daten) oder umgekehrt. Wie auch immer, er erwartet scheinbar genau das Gegenteil.

[kuemmelchen]

Ich habe verschiedene Konstellationen getestet, aber der Fehler bleibt.

Kontrolldatei :
INFILE mit "var 2"
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\n'

und Datendatei (hinter Amerika ist die Datei zu Ende):

141,Deutschland,092,Amerika

liefert das Ergebnis: 2 logische Datensätze. Vollkommen richtig.

Mit der Datendatei (hinter Amerika ist die Datei zu Ende und hinter Deutschland wurde die ENTER-Taste gedrückt):

141,Deutschland
092,Amerika

liefert das Ergebnis:

Commit-Punkt erreicht - Anzahl der logischen Datensõtze 2
SQL*Loader-501: Datei (regions_var.txt) kann nicht gelesen werden
SQL*Loader-566: Unvollstõndiger Datensatz am Ende von Datendatei gefunden
SQL*Loader-2026: Der Ladevorgang wurde abgebrochen, weil SQL Loader nicht fortfahren kann.

Eingetragen wird aber nur der erste logische Datensatz. Enthält die Datendatei einen dritten Datensatz, so wird der Fehler
SQL*Loader-563: Falsche Lõnge f³r VAR-Datensatz
ausgegeben.

Nur als Anmerkung: infile mit "fix " bzw. "str " funktionieren perfekt, auch wenn pro Zeile ein Datensatz angegeben wird.

Ich vermute, dass bei var ein Bug vorliegt. Mal sehen, ob das neueste Patch (Patch 14 zu 10.2.0.5.0) Abhilfe verschaffen wird.

kuemmelchen

[jum]

Welches Hex-Zeichen schließt die Datei ab?
Ich habe es jetzt auch unter 10.2.0.4.0 geprüft, es klappt mit CR=x0d am Zeilen- und Dateiende.

141,Deutschland
102,Amerika
083,Polen

31 34 31 2c 44 65 75 74 73 63 68 6c 61 6e 64 0d
31 30 32 2c 41 6d 65 72 69 6b 61 0d 
30 38 33 2c 50 6f 6c 65 6e 0d

Obige Fehlermeldung ehalte ich bei CR/LF=x0d x0a, kein Einlesen erfolgt ohne spezielles Zeichen am Dateiende bzw. mit x00.

[kuemmelchen]

Ich habe meine Daten-Datei mit einem Hex-Editor bearbeitet. Das Zeilenende wurde auf od geändert. Die Daten werden jetzt korrekt geladen.

Bei großen Daten-Dateien wäre diese Vorgehensweise aber recht aufwendig. Was ist, wenn kein Hex-Editor zur Verfügung steht?

Gibt es eine einfache Möglichkeit, solche Daten-Dateien auch ohne Hex-Editor zu erstellen/zu bearbeiten?

kuemmelchen

[jum]

Das könnte leicht mit UNIX-Tools wie awk, grep, tr geschehen.
Alternativ ist es ein Zeichen mehr und dafür müsste die Länge angepasst werden:

151,Deutschland
112,Amerika
093,Polen

31 35 31 2c 44 65 75 74 73 63 68 6c 61 6e 64 0d 0a
31 31 32 2c 41 6d 65 72 69 6b 61 0d 0a 
30 39 33 2c 50 6f 6c 65 6e 0d 0a

Muss hier eigentlich die Form mit variabler Recordlänge "var 2" verwendet werden, ohne diese Länge, nur mit Separator wäre die Sache einfacher ?

[kuemmelchen]

Nur zur Info:

Wenn in der Kontrolldatei folgendes geschrieben wird:

INFILE mit "var 2"
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '\n\r'

dann muss in der Datendatei die Länge um ein Zeichen erweitert werden:

151,Deutschland
112,Amerika

Die Datendatei wurde mit dem Editor von Microsoft erstellt.

@jum
Die Varianten mit fix und str sind da doch besser.

kuemmelchen

[jum]

@kuemmelchen - genau das habe ich doch geschrieben

151,Deutschland
112,Amerika
093,Polen

Übrigens ist es in diesem Fall egal, was man verwendet für OPTIONALLY ENCLOSED BY:
OPTIONALLY ENCLOSED BY '\n\r'
OPTIONALLY ENCLOSED BY '\n'
OPTIONALLY ENCLOSED BY "'"
oder diese Klausel ganz weglässt.