dbimport problem...
A user dbexport'ed a database from IDS 7.30 on Linux and FTP'd the files (in ASCII mode) to an IDS 9.40 Linux box, where dbimport failed with "Load file has different number of columns than table"; the export files appeared to have 2-byte (CR/LF) line endings while the target expected 1 byte. Replies suggested using binary FTP instead, since ASCII mode alters line endings, but the poster reported neither mode helped. Jonathan Leffler asked for a hex/od dump to confirm CRLF and suggested stripping CR with tr -d '\\\\015'. No confirmed resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi all!
Have an interesting problem...
making dbexport on server "A"
OS: Linux tester 2.2.16-22smp #1 SMP Tue Aug 22 16:39:21 EDT 2000 i686
unknown
IDS: 7.30.UC10
do ftp in ASCII-mode to server "B"
OS: Linux adm-eserver 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005 i686
i686 i386 GNU/Linux
IDS: 9.40.UC6
When try do do dbimport, get the next error...
Load file has different number of columns than table
Found this:
On server "A" after dbexport end of line in text files consists of 2
bytes,
but on server "B" end of line in text files consists of 1 byte.
Can server "B" be tuned up to understand files with end of line of 2
bytes ???
thank you in advance for any help!!!
svs wrote:
> Hi all!
> Have an interesting problem...
>
> making dbexport on server "A"
> OS: Linux tester 2.2.16-22smp #1 SMP Tue Aug 22 16:39:21 EDT 2000 i686
> unknown
> IDS: 7.30.UC10
>
> do ftp in ASCII-mode to server "B"
> OS: Linux adm-eserver 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005 i686
> i686 i386 GNU/Linux
> IDS: 9.40.UC6
>
> When try do do dbimport, get the next error...
> Load file has different number of columns than table
>
> Found this:
> On server "A" after dbexport end of line in text files consists of 2
> bytes,
> but on server "B" end of line in text files consists of 1 byte.
>
> Can server "B" be tuned up to understand files with end of line of 2
> bytes ???
>
>
> thank you in advance for any help!!!
>
Use binary mode to ftp, ascii appends CR at the end of every line.
HTH
Michael
Hi,
why don't you use binary mode for the FTP ?
This should avoid the stripping of the byte you're missing,
i.e. the files should be exactly the same on both machines
(after all they're both Linux on x86).
With that the dbimport should work ...
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
informix-list-bounces@iiug.org wrote on 17.02.2006 15:01:35:
> Hi all!
> Have an interesting problem...
>
> making dbexport on server "A"
> OS: Linux tester 2.2.16-22smp #1 SMP Tue Aug 22 16:39:21 EDT 2000 i686
> unknown
> IDS: 7.30.UC10
>
> do ftp in ASCII-mode to server "B"
> OS: Linux adm-eserver 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005 i686
> i686 i386 GNU/Linux
> IDS: 9.40.UC6
>
> When try do do dbimport, get the next error...
> Load file has different number of columns than table
>
> Found this:
> On server "A" after dbexport end of line in text files consists of 2
> bytes,
> but on server "B" end of line in text files consists of 1 byte.
>
> Can server "B" be tuned up to understand files with end of line of 2
> bytes ???
>
>
> thank you in advance for any help!!!
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
it doesn't work (binary , ascii)...
svs wrote: > it doesn't work (binary , ascii)... Please - give us a clue as to what you are commenting on. Yes - Google requires care. If you read the news group via Google Groups and hit the obvious 'reply' link, you don't get the original article quoted. So, don't choose that - choose the 'more options' link, then hit reply; that includes the prior posting (which should be trimmed) and you then add your posting underneath. If you weren't using Google Groups, please include enough information from the prior message to give people the context necessary to understand your comment. I use a threaded news reader - but your response is to a thread I'd already read, so I don't have the previous articles to read. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
svs wrote:
> Have an interesting problem...
>
> making dbexport on server "A"
> OS: Linux tester 2.2.16-22smp #1 SMP Tue Aug 22 16:39:21 EDT 2000 i686
> unknown
> IDS: 7.30.UC10
>
> do ftp in ASCII-mode to server "B"
> OS: Linux adm-eserver 2.6.9-5.EL #1 Wed Jan 5 19:22:18 EST 2005 i686
> i686 i386 GNU/Linux
> IDS: 9.40.UC6
>
> When try do do dbimport, get the next error...
> Load file has different number of columns than table
>
> Found this:
> On server "A" after dbexport end of line in text files consists of 2
> bytes,
> but on server "B" end of line in text files consists of 1 byte.
>
> Can server "B" be tuned up to understand files with end of line of 2
> bytes ???
In response to a couple of suggestions to use binary transfers in FTP
(which I suspect would have happened anyway), you said it makes no
difference.
So, we need to know exactly what you mean by 'on server A, end of line
consists of 2 bytes, but on server B, end of line consists of 1 byte'.
Do you mean that server A is producing CRLF (carriage-return, line-feed)
at the ends of the lines? Can you show us the output of a hex dump or
equivalent (hd, or od -c, perhaps) of the first line or two of the files
on A? If you've got a CRLF problem, can you fix it reliably with the
'tr' command? You probably can; use "tr -d '\\015'" to delete ^M
(control-M) characters.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/