ERROR: Teradata row not delivered (trget): Right truncation of string data

[Patrick]

Hi all,

I'm running code like below.

libname rx teradata server="abc5xyz.teradata.company.com.au" authdomain = "Teradata Auth" schema=rx /* mode=Teradata */;
proc sql;
	create table test as
		SELECT my_column
		FROM rx.tera_table
	;
quit;
libname rx clear;

If not using mode=Teradata in the libname, I'm receiving below error. 
ERROR: Teradata row not delivered (trget): Right truncation of string data.

But... Some (not all) other users can execute the exactly same code in the same environment and without mode=Teradata without receiving an Error - both via batch and EG. The only real differences between these users I can think are Teradata permissions ...but that doesn't really make sense to me.

Any ideas or experience what could be happening here?

Cheers, Patrick

[LinusH]

Agree that permission doesn't make sense, unless you are using row-level permissions.

Assumed you have tried tracing to get more information out?

options sastrace="d,,,ds" sastraceloc=saslog nostsuffix msglevel=i;

[Patrick]

Thank you @LinusH and @Tom 

Yes, Teradata is on Unicode and SAS on LATIN1 which is the root cause for the error. 

I believe I figured out what the issue is (have to fully verify next week when back at work):

The SAS SQL accesses a Teradata View that sources from another Teradata view. I can only access the first (last in the chain) view.

Data protection has lately been tightened and I've realised that the account_id's I'm getting are masked (hex string). 

The users (user id's) that still can execute the SAS script without mode=Teradata are used for production runs and certainly need clear-text data. 

My guess is that these users got additional/different Teradata permissions and that the Teradata view defines the account_id column with a different definition (=likely not as Unicode) for these users.

[Yough1967]

My advice — even if others aren’t hitting it, it could be due to differences in default string lengths or client-side SAS settings. Try explicitly setting the length for my_column in your proc sql query, e.g.,

select cast(my_column as varchar(1000)) as my_column

[Tom]

If you are querying data that is using a single byte encoding (such as LATIN1) and running SAS using UTF-8 encoding then some characters could go from using one byte to using two or more bytes.  Which could cause the same string of bytes to grow in length.

What are the different SAS sessions using for the value of the SAS system option ENCODING?

You can run this simple statement to see the setting in the SAS log.

%put %sysfunc(getoption(encoding));