LOAD DATA: NULL im letzten Feld falsch importiert

Hallo,

was ist denn hiervon zu halten:

Es liegen verschiedene Textdateien vor, die nach MySQL importiert werden
sollen. Tab als Feldtrenner, Zeilenumbruch als Satztrenner, Textfelder
werden nicht von Gänsefüßchen o.ä. umschlossen, für NULL steht =
\N. Mit
"LOAD DATA INFILE ... INTO TABLE xxx", ohne weitere Optionen, wird alles
richtig importiert, mit einer Ausnahme:

Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
Datenbankfeld nicht NULL, sondern der jeweils von MySQL angenommene
"leere" Wert, also 0.00 bei einem Zahlenfeld, das beliebte "0000-00-00"
für ein Datumsfeld usw. In die anderen Felder kommt brav NULL, wie es
sein soll.

Das Handbuch äußert sich nicht zu dieser Merkwürdigkeit (jedenfalls=

nicht unter "LOAD DATA INFILE"), Google bringt mich mit dem Suchbegriff
"LOAD DATA INFILE" allein auch nicht weiter. Und das Problem kommt im
absolut falschen Augenblick über mich, es eilt.

Nur zur Abwechslung tut in diesem Fall mal phpMyAdmin (2.8.0.3) korrekt,
aber da müssten dann alle 6 Tabellen einzeln aufgebaut werden.

MySQL 5.0.18 unter Windows XP.

Danke für jederlei Hilfe, weiterführende Fragen, bessere
Google-Stichworte oder was auch immer.

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: LOAD DATA: NULL im letzten Feld falsch importiert

Sibylle Koczian schrieb:

> Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
> Datenbankfeld nicht NULL, sondern der jeweils von MySQL angenommene
> "leere" Wert, also 0.00 bei einem Zahlenfeld, das beliebte "0000-00-00"
> für ein Datumsfeld usw. In die anderen Felder kommt brav NULL, wie es
> sein soll.

Kann es sein, dass dieses letzte Feld als NOT NULL definiert ist?

Gruß. Claus

Re: LOAD DATA: NULL im letzten Feld falsch importiert

Sibylle Koczian schrieb:
> Hallo,
>
> was ist denn hiervon zu halten:
>
> Es liegen verschiedene Textdateien vor, die nach MySQL importiert werden
> sollen. Tab als Feldtrenner, Zeilenumbruch als Satztrenner, Textfelder
> werden nicht von Gänsefüßchen o.ä. umschlossen, für NULL steht \N. Mit
> "LOAD DATA INFILE ... INTO TABLE xxx", ohne weitere Optionen, wird alles
> richtig importiert, mit einer Ausnahme:
>
> Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
> Datenbankfeld nicht NULL, sondern der jeweils von MySQL angenommene
> "leere" Wert, also 0.00 bei einem Zahlenfeld, das beliebte "0000-00-00"
> für ein Datumsfeld usw. In die anderen Felder kommt brav NULL, wie es
> sein soll.
>
> Das Handbuch äußert sich nicht zu dieser Merkwürdigkeit (jedenfalls
> nicht unter "LOAD DATA INFILE"), Google bringt mich mit dem Suchbegriff
> "LOAD DATA INFILE" allein auch nicht weiter. Und das Problem kommt im
> absolut falschen Augenblick über mich, es eilt.
>

Hallo Sibylle,

Ich würde es mit einem Bug-Report probieren. Nach meiner Erfahrung
reagieren die Entwickler da ziemlich schnell drauf.

Christian

Re: LOAD DATA: NULL im letzten Feld falsch importiert

Claus Reibenstein schrieb:
> Sibylle Koczian schrieb:
>=20
>=20
>>Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
>>Datenbankfeld nicht NULL, sondern der jeweils von MySQL angenommene
>>"leere" Wert, also 0.00 bei einem Zahlenfeld, das beliebte "0000-00-00"=

>>für ein Datumsfeld usw. In die anderen Felder kommt brav NULL, wie es=

>>sein soll.
>=20
>=20
> Kann es sein, dass dieses letzte Feld als NOT NULL definiert ist?
>=20

Nein. Es sind mehrere Tabellen, es betrifft immer das jeweils letzte
Feld der Importdatei, und nicht eins von diesen Feldern ist als NOT NULL
definiert.

Es kommt übrigens noch etwas hinzu: die Tabellen selbst enthalten
jeweils noch ein Timestamp-Feld. Das kommt in der Tabellendefinition am
Ende und hat als Default "CURRENT_TIMESTAMP". Ich hatte ursprünglich
angenommen, dass auch bei LOAD DATA INFILE ein solches Feld automatisch
seinen Defaultwert bekommt, wenn die Importdatei keine Daten dafür
enthält, analog zu INSERT - aber tatsächlich bekommt es den Wert
"0000-00-00 00:00:00".

Jetzt habe ich erst mal beide Probleme auf einmal umgangen, indem Datum
und Uhrzeit bei jedem Satz schon in die Importdaten geschrieben werden:
dann kommt ein Timestamp-Wert zustande, der der Wahrheit zumindest nahe
kommt (das reicht im konkreten Anwendungsfall) und das letzte Feld beim
Import ist nicht NULL.

Dank und Gruß,
Sibylle

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE

Re: LOAD DATA: NULL im letzten Feld falsch importiert

Sibylle Koczian schrieb:

> Claus Reibenstein schrieb:
>
>> Sibylle Koczian schrieb:
>>
>>> Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
>>> Datenbankfeld nicht NULL [...]
>>
>> Kann es sein, dass dieses letzte Feld als NOT NULL definiert ist?
>
> Nein. Es sind mehrere Tabellen, es betrifft immer das jeweils letzte
> Feld der Importdatei, und nicht eins von diesen Feldern ist als NOT NULL
> definiert.

Dann dürfte es wohl ein Bug sein und verlangt nach einem Bugreport,
falls er nicht schon bekannt ist.

Gruß. Claus

Re: LOAD DATA: NULL im letzten Feld falsch importiert

Sibylle Koczian wrote:
> Claus Reibenstein schrieb:
>> Sibylle Koczian schrieb:
>>
>>> Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
>>> Datenbankfeld nicht NULL, sondern der jeweils von MySQL angenommene
>>> "leere" Wert, also 0.00 bei einem Zahlenfeld, das beliebte "0000-00-00"
>>> für ein Datumsfeld usw. In die anderen Felder kommt brav NULL, wie es
>>> sein soll.

> Es sind mehrere Tabellen, es betrifft immer das jeweils letzte
> Feld der Importdatei, und nicht eins von diesen Feldern ist als NOT NULL
> definiert.

Das könnte tatsächlich ein Bug sein. Schreib einen Bugreport.

> Es kommt übrigens noch etwas hinzu: die Tabellen selbst enthalten
> jeweils noch ein Timestamp-Feld. Das kommt in der Tabellendefinition am
> Ende und hat als Default "CURRENT_TIMESTAMP". Ich hatte ursprünglich
> angenommen, dass auch bei LOAD DATA INFILE ein solches Feld automatisch
> seinen Defaultwert bekommt, wenn die Importdatei keine Daten dafür
> enthält, analog zu INSERT - aber tatsächlich bekommt es den Wert
> "0000-00-00 00:00:00".

Das ist wirklich seltsam.

> Jetzt habe ich erst mal beide Probleme auf einmal umgangen, indem Datum
> und Uhrzeit bei jedem Satz schon in die Importdaten geschrieben werden:
> dann kommt ein Timestamp-Wert zustande, der der Wahrheit zumindest nahe
> kommt (das reicht im konkreten Anwendungsfall) und das letzte Feld beim
> Import ist nicht NULL.

Vielleicht willst du ja nochmal probieren was passiert, wenn du LOAD
DATA INFILE eine Spalten-Liste (für die tatsächlich existierenden
Felder im CSV) mitgibst. Spätestens dann sollte das Default-Handling
für die übrig gebliebenen Spalten greifen.

Ein weiterer Workaround wäre, LOAD DATA INFILE mit
SET =CURRENT_TIMESTAMP anzureichern. Das steht sogar
so als Beispiel im Handbuch.


XL

Re: LOAD DATA: NULL im letzten Feld falsch importiert

Sibylle Koczian wrote:

> Hallo,
>
> was ist denn hiervon zu halten:
>
> Es liegen verschiedene Textdateien vor, die nach MySQL importiert werden
> sollen. Tab als Feldtrenner, Zeilenumbruch als Satztrenner, Textfelder
> werden nicht von Gänsefüßchen o.ä. umschlossen, für NULL steht \N. Mit
> "LOAD DATA INFILE ... INTO TABLE xxx", ohne weitere Optionen, wird alles
> richtig importiert, mit einer Ausnahme:
>
Da Du unter Windows arbeitest: was genau meinst Du mit "Zeilenumbruch"? Das
Windows-übliche \r\n (Hex 0D 0A oder dezimal 13 10) oder das UNIX-übliche
\n (also nur 0A = 10)? MySQL erzeugt (bei SELECT INTO OUTFILE) und erwartet
(bei LOAD DATA INFILE) nur \n oder Du musst es ihm anders sagen. Auch dann,
wenn der Server unter Windows läuft.

> Wenn im letzten Feld eines Satzes \N steht, dann kommt in dieses
> Datenbankfeld nicht NULL, sondern der jeweils von MySQL angenommene
> "leere" Wert, also 0.00 bei einem Zahlenfeld, das beliebte "0000-00-00"
> für ein Datumsfeld usw. In die anderen Felder kommt brav NULL, wie es
> sein soll.
>
Ich habe mal versucht, das nachzuvollziehen, auch unter Windows XP
(allerdings MySQL 5.0.24, aber das ist wohl egal). Ohne Optionen für den
Zeilenumbruch passiert so was dann, wenn Deine Textdateien
Windows-Zeilenumbrüche enthalten. Und das ist auch nicht wirklich
überraschend: der Feldinhalt, wie MySQL ihn sieht, ist ja in diesem Fall
nicht '\N', sondern '\N\r'. In einem Zahlen- oder Datumsfeld müsste so was
eigentlich ganz und gar zurückgewiesen werden, aber wir kennen ja unser
MySQL; hast Du es mal mit "strict SQL mode" versucht? Und was kommt denn
heraus, wenn Dein letztes Datenfeld CHAR, VARCHAR oder TEXT ist?

> Das Handbuch äußert sich nicht zu dieser Merkwürdigkeit (jedenfalls
> nicht unter "LOAD DATA INFILE"), Google bringt mich mit dem Suchbegriff
> "LOAD DATA INFILE" allein auch nicht weiter. Und das Problem kommt im
> absolut falschen Augenblick über mich, es eilt.
>
Ich hoffe, diese Tatsache hat Dich von einem übereilten Bugreport erst
einmal abgehalten.

Gruß,
Hertha