it appears that the copy command is treating the input as octal.

If you convert the backslash \ into its octal equivalent, \134 then it “works”.

In some cases, such as \700 an error is thrown.

With an import file test.txt:

ONE\101
ONE\134101

When imported into table test (test varchar(20)), you get:

ONEA
ONE\101

So the copy command is converting octal to UTF-8,ASCII equivalent.

Andy Barlow


On 25 Sep 2015, at 14:30, andy.barlow@datum360.com wrote:

I filed a bug earlier, the gist of which is below but perhaps there is some setting or flag I am missing when importing?

If your import file contains a number of character combinations, such as \560, \561, \700 and probably lots of others, the copy into fails with a message like:

Failed to import table line 5 field 1 'varchar(20)' expected in 'FIVE\700'


Reproducible: Always

Steps to Reproduce:
1. create table test (test varchar(20));
2. create a load file test.txt with the following:
ONE
TWO
THREE
FOUR
FIVE\700
3. copy into test from 'test.txt' using delimiters '\t','\n';
4. fails with message:
Failed to import table line 5 field 1 'varchar(20)' expected in 'FIVE\700'
Actual Results:  
Failed to import table line 5 field 1 'varchar(20)' expected in 'FIVE\700'

Expected Results:  
should import OK, the character combinations are valid

Andy Barlow
Datum360