Results 1 to 2 of 2
  1. #1
    Join Date
    Aug 2003
    Posts
    2

    Unanswered: Load file has different number of columns than table

    We try to DBIMPORT unload files that were DBEXPORTED from the same machine. This is on NT. This results in an error Load file has different number of columns than table on one of the files.
    The statement is:

    { TABLE "mydb".dbglobal row size = 66 number of columns = 2 index size = 21 }
    { unload file name = dbglo00107.unl number of rows = 5 }

    create table "mydb".dbglobal
    (
    global_code char(10),
    global_value text
    );
    Load file has different number of columns than table
    What we found out so far that it looks like the DBIMPORT has a problem with the PIPE-character in the TEXT-field. The 'PIPE's' are escaped and it looks like it's going wrong there.

    We DBEXPORTed a file from a UNIX machine and imported it on NT and this doesn't result in errors. So it has to be an issue with NT and the sequence of ESC-PIPE-CRLF

    We tried to use utils like UNIX2DOS to change the CRLF codes (which is a difference between UNIX and NT) but that doesn't solve the problem and gives the same error.

    Anyone any clue?

    All suggestions are welcome.

    Regards,

    Léon.
    Last edited by LDeeJay; 08-04-03 at 07:17.

  2. #2
    Join Date
    Aug 2003
    Posts
    2

    Not all text exported (was Load file has different number of columns)

    We narrowed the problem down to an incorrect DBEXPORT. Some of the TEXT fields (BLOBS) do not export completely. In the case the contents of that field is broken off after the escape & pipe characters and leaving out any text still to come, the columnnumbers do not match 'cause there's one extra. Informix treats this correctly: there are extra columns.

    But then it raises the question: why is not all information exported? In some fields it's around character 300, in another field around character 700 so it's not the field length. We also see that it's not a specific character that causes the export to end the field. The next field in that table is exported correctly.

    Anyone seen this behaviour before?
    Anyone any suggestions?

    Thanks in advance.

    Regards,

    Léon.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •