external Table und dateiformate

shureg

Professional

Posts: 202

Friday, August 13th 2010, 9:47pm

external Table und dateiformate

Moin,
folgendes Problem, heute auf der Arbeit habe ich eine External Table zum Parsen einer Textdatei, die folgendes Format hatte: 2010-11-01 12:12:12,xxxx,1234....
und so weiter. Es gab gleich beim ersten feld ein problem, da ich das feld als date definiert habe und als format "yyyy-mm-dd hh24:mi:ss" und das sind 19 Zeichen
Problem, das in dieser Datei nach jeden Zeichen noch das chr(0) steht und somit das feld dann mindestens doppelt so lang ist.
die frage liegt das an der codierung der datei? normaler weise sollte diese in iso-8859-1 codiert sein.
oder könnte die datei beim upload kaputt gegangen sein? woher kommen die Zeichen überhaupt? habe die kleine datei dann im utf-8 format abgespeichert und das wurde dann ohne probleme üebrnohmen.
leider sind die meisten dateien über 200 mb, die nicht so einfach neu abgespeichert werden können.

wenn es ein charset problem ist, müsste es ja mit CHARACTERSET '' behoben sein, habe aber iso-8859-1 ausprobiert und hat nicht geholfen.

hat sich jemand schon mal mit ähnlichen problem beschäftigt?

Latest blogs: bin unter den 20 glücklichen...

Torben Brodt

Administrator

Posts: 8,454

Saturday, August 14th 2010, 10:32am

Zahlen und Striche sind in ISO, genau wie in UTF8 kodiert.
Kleiner Beweis:

	PHP Quellcode
1 2 3	$s = '2010-11-01'; echo utf8_encode(utf8_encode(utf8_encode($s))); // Ausgabe = 2010-11-01

Mit welchem DBMS und mit welchem Typ arbeitest du konkret?
Der korrekte Typ für deine Spalte wäre DATETIME - nicht DATE

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

shureg

Professional

Posts: 202

Saturday, August 14th 2010, 8:59pm

wir haben oracle im einsatz.
das problem ist, dass das datum im editor auch so aussieht 2010-11-01, aber wenn man diese dann im hex genau betrachtet steht nach jedem zeichen noch das chr(0)(bzw null-wert) was im editor nicht sichtbar ist
beim parsen aber schon, da es dann eben keine 19 zeichen lang ist sonderen 38

Latest blogs: bin unter den 20 glücklichen...

Torben Brodt

Administrator

Posts: 8,454

Saturday, August 14th 2010, 9:07pm

Also redest du gar nicht von der Datenbank? Wer zeigt die chr(0)'er an? Der Editor? Ein Oracle Client?
Ich kann dir nicht sagen, wer die Zeichen jetzt konkret einbaut, aber es kann mehrere Gründe haben.
Für mich stellt sich nur die Frage: Ignoriere was der Editor sagt. Oracle kennt Datetime und es wird sowieso kein echter String mit einer Stringlänge gespeichert - also was passiert wenn du den Eintrag in die Datenbank machst?

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

shureg

Professional

Posts: 202

Sunday, August 15th 2010, 12:26pm

also damit wir uns auch richtig verstehen.

zum einlesen der datei, habe ich eine externeltable gemacht, vereinfacht mit 2 Spalten

Source code

create table ext_test (
  i   Date,
  n   Varchar2(20)
)
organization external (
  type              oracle_loader
  default directory test_dir
  access parameters (
    records delimited  by newline
    fields  terminated by ','
    missing field values are null
    (
     i date 'yyyy-mm-dd' -- länge 10 zeichen
     ,n                              --länge max 20 Zeichen
    )
  )
  location ('testfile')
)
reject limit unlimited;

ich habe diese testfiledatei wo tausende von zeilen stehen, die aus 2 spalten bestehen. Datum und irgendein text.
beim

	Source code
1	select* from ext_test

dir mir nun eigentlich die datei in der tabelle anzeigen sollte, wurde ne logdatei geschrieben wo es stand das, dass erste feld(i) zu lang ist und nicht gematcht werden kann.

nun hbe ich eine weitere externaltable geschrieben und die nur ein feld varchar(4000) hat und den inhalt der einen zeile hat...
das hanze wurde natürlich ohne probleme gematcht und beim select auch angezeigt.
dann habe ich auf die spalte ein dump und den hexwert jedes zeichens anzuzeigen gemacht und siehe da, nach jedem wert stand ebeb 00 also als beispiel für 123, 3100 3200 3300, statt 3132 33

oracle hat diese bestimmt nicht eingebaut, da die datei von anfang an so geliefert wurde, ich weiss jetzt nicht ob das ganze mit enconding zu tun hat und man es durch angabe bestimmter CHARACTERSET angabe beheben kann oder ist die datei einfach nur kaputt

für angabe datum mit zeit brauch man in oracle keine datetime datentype, date speichert sowohl mit als auch ohne zeitangabe

Latest blogs: bin unter den 20 glücklichen...

Torben Brodt

Administrator

Posts: 8,454

Sunday, August 15th 2010, 1:35pm

Hey,
dieses Oracle übersteigt leider mein SQL'92er Wissen

Hast du denn inzwischen mal versucht die Textdateien neu abzuspeichern? Der VI macht auch bei großen Dateien keine Probleme

Ansonsten durch ein sed pipen - machen wir auch regelmäßig mit großen Datenmengen.

Lg

Latest blogs: Neuer EX4 Server, Java EE Summit im Juni in München, Kostenlos zur Cebit + Windows 8 Entwickler Schulung

shureg

Professional

Posts: 202

Sunday, August 15th 2010, 1:48pm

achso..
ne habe ich noch nicht, werde erst morgen ausprobieren, ist ein problem auf der arbeit.
weiss nicht ob wir vi drauf haben..
wie mach ich das mit sed?

Latest blogs: bin unter den 20 glücklichen...

shureg

Professional

Posts: 202

Monday, August 16th 2010, 6:47pm

heute habe ich noch mal rumprobiert und festgestellt, das die datei in utf-16 format war...
wusste garnicht, wenn am anfang FFFE steht, das es sich um Unicode handelt.

Mit dem Datum habe ich es immer noch nicht hinbekommen, aber als string list er es schon mal ein

Latest blogs: bin unter den 20 glücklichen...