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