external Table und dateiformate

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • 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?
    MfG ShureG

    There are 10 kinds of people. Those who understand binary notation, and those who do not.
  • 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
    MfG ShureG

    There are 10 kinds of people. Those who understand binary notation, and those who do not.
  • 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?
  • also damit wir uns auch richtig verstehen. :)
    zum einlesen der datei, habe ich eine externeltable gemacht, vereinfacht mit 2 Spalten

    Source Code

    1. create table ext_test (
    2. i Date,
    3. n Varchar2(20)
    4. )
    5. organization external (
    6. type oracle_loader
    7. default directory test_dir
    8. access parameters (
    9. records delimited by newline
    10. fields terminated by ','
    11. missing field values are null
    12. (
    13. i date 'yyyy-mm-dd' -- länge 10 zeichen
    14. ,n --länge max 20 Zeichen
    15. )
    16. )
    17. location ('testfile')
    18. )
    19. reject limit unlimited;
    Display All


    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
    MfG ShureG

    There are 10 kinds of people. Those who understand binary notation, and those who do not.
  • 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
    MfG ShureG

    There are 10 kinds of people. Those who understand binary notation, and those who do not.