All Forums Teradata Studio
dae 13 posts Joined 07/12
20 Apr 2015
[TERADATA STUDIO][SMARTLOAD][Unable to load an ASCII character]

Using "Smart Load" Function, I get an error (cf. below) loading my file with a character whose decimal code=130.
As an extended ASCII code, I thought that using "File Encoding = ISO-8859-1", I would have been able to load that file ... but it fails !
Do I have to upgrade my JDBC driver version ?
The Teradata Studio Version is:
Thanks a lot for any kind of help you can give me,

Starting Load...
Load Task
Loading data...
Warning(s) occurred while inserting data.

Row number 1 had an error.
Cause = com.teradata.jdbc.jdbc_4.util.JDBCException: [Teradata Database] [TeraJDBC] [Error 6706] [SQLState HY000] The string contains an untranslatable character.; 
Data loaded successfully with Warning(s)
1 Rows Processed
0 Rows Loaded

Row number 1 had an error.
Cause = com.teradata.jdbc.jdbc_4.util.JDBCException: [Teradata Database] [TeraJDBC] [Error 6706] [SQLState HY000] The string contains an untranslatable character.; 


fgrimmer 553 posts Joined 04/09
20 Apr 2015

Didier, The JDBC Driver should be fine since Studio bundles the latest version. Untranslatable character indicates that the data can not be loaded into the column. What happens when you try UTF-8 file encoding? Or do you need to change the character set for the column before loading the data?

Chuckbert 78 posts Joined 07/09
21 Apr 2015

There are more than one character sets involved. First, there is the character encoding of the file that is being read. That is specified in the smart load dialog. Then there is the session character set specified as the CHARSET JDBC property in the connection profile. And there is the character set of the column the data will be stored in.
When I used the default value of the "CHARSET" JDBC Connection Property ("UTF8"), I get the untranslatable character message. When I set the "CHARSET" property to "LATIN" the data is inserted. I haven't checked to see if selecting the column results in the same odd character being in the result.
The Server Character Sets chapter of the International Character Set Support document says the following:

Differences Between ASCII and Teradata LATIN

When used in the Teradata Database, ASCII and Teradata LATIN are identical on all code

points except the 80-FF range, where Teradata LATIN defines additional West European


Code points outside the seven-bit ASCII range result in data that may not behave as intended.


Maybe this case is one of those that is not behaving as intended.


Perhaps the following from the International Character Set Support document has a clue:

Using LATIN Characters Above ASCII X'7F'

If you intend to use characters with code points above ASCII X’7F’, take the following steps:

1 Install, as appropriate, LATIN1_0A, LATIN9_0A, EBCDIC037_0E, or a site-defined

character set that matches the character set used on your client.

2 Set the client character set to LATIN1_0A, LATIN9_0A, EBCDIC037_0E, or the name of

the site-defined character set that you installed in Step 1 in order to use the encodings.

The preceding applies if non-ASCII characters are desired.



dae 13 posts Joined 07/12
21 Apr 2015

Thanks a lot for your answer ...
Reading "International Character Set Support" Volume (TD V14.10), I could notice the restriction below about "ISO 8859-1" (Latin1) Encoding (p.65):
1.  "Teradata Database Japanese language facilities support ISO 8859-1 (Latin1) with the restriction that the code points 80XC -85XC are not allowed."
2. "This restriction is scheduled to be removed in a future release."
I think those two features can explain the failure we had, the code I had to deal with being '82XC' (130 in decimal system as I said earlier).

You must sign in to leave a comment.