topic Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE in SAS Enterprise Guide

Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

daily — Thu, 06 Jul 2017 10:48:42 GMT

while i was tryed to submited this:

PROC SQL; SELECT *FROM DICTIONARY.TABLES WHERE UPCASE(LIBNAME)=”CRM_ANAL”; QUIT;

getting Error:

an occured excuting the workspace job "program" Integration technologies failed to submerror it the code. [Error] Failed to transcode data from U_UTF8_CE to U_LATIN9_CE encoding because it contained charectores which are not supported by your sas session encoding .please review your encoding= and local= SAS system options to ensure that they can accommodate the data that you want to process. A portion of the source string ,in hex representation is:[None]7fe808107 ce4:3b 2a 27 3b 2a 2f 3b 71 75 69 74 72 |;*';*";*/;quit;r| [None]7fe808107 cf4:75 6e 3b 0d 0a 4f 50 54 49 4f 4e 53 20 50 41 47 |un;..OPTIONS PAG| [Error]Some code points did not transcode. please give detail guide lines for how to config .

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

daily — Thu, 06 Jul 2017 10:52:21 GMT

hi team ,

please help for above error and resolve me .

please give detail information.

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

Patrick — Thu, 06 Jul 2017 11:13:41 GMT

@daily

That looks like an interesting problem.

UTF-8 is a multi byte character set but U_LATIN9_CE is single byte.

Multi byte character sets can encode many more characters than single byte so it can happen that a multi byte character simply can't get mapped into a single byte character. That's when SAS throws the Error you get.

What I've never seen before is that this can also happen with SAS dictionary tables. The only explanation I have in the moment:

Your SAS session runs in single byte, your libref CRM_ANAL points to a data base which is in UFT-8 and at least one of the table names in this data base uses a multi byte character which can't get mapped into U_LATIN9_CE.

I suggest you raise this issue with SAS TechSupport.

To test my theory: Can you please run below code and let us know the outcome? MEMNAME is the only column I can see which could contain such non-mappable characters and though a SQL which doesn't return this column should work.

proc sql;
  select 
    libname, 
/*    memname, */
    memtype, 
    dbms_memtype, 
    memlabel, 
    typemem, 
    crdate, 
    modate, 
    nobs, 
    obslen, 
    nvar, 
    protect, 
    compress, 
    encrypt, 
    npage, 
    filesize, 
    pcompress,
    reuse, 
    bufsize,
    delobs, 
    nlobs,
    maxvar,
    maxlabel,
    maxgen,
    gen,
    attr, 
    indxtype, 
    datarep, 
    sortname, 
    sorttype,
    sortchar,
    reqvector, 
    datarepname, 
    encoding, 
    audit, 
    audit_before, 
    audit_admin,
    audit_error, 
    audit_data, 
    num_character, 
    num_numeric
  from DICTIONARY.TABLES
    WHERE UPCASE(LIBNAME)="CRM_ANAL";
quit;

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

Kurt_Bremser — Thu, 06 Jul 2017 11:45:59 GMT

If you really used this:

”CRM_ANAL”

in your code, then it's no miracle. These are not standard double quotes, but double quotes from some NLS character set, and therefore UTF coded (hex e2 80 9d). Use standard double quotes.

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

Patrick — Thu, 06 Jul 2017 11:46:30 GMT

@Kurt_Bremser

I guess that happened because the OP copied the code first into MS WORD or the like. But such quotes would create a syntax Error and not the Error the OP posted.

27         proc sql;
28           select *
29           from DICTIONARY.TABLES
30             where libname = ”WORK”;
                               _
                               22
                               200
ERROR 22-322: Syntax error, expecting one of the following: a name, a quoted string, a numeric constant, a datetime constant, 
              a missing value, (, *, +, -, ALL, ANY, BTRIM, CALCULATED, CASE, INPUT, PUT, SELECT, SOME, SUBSTRING, TRANSLATE, 
              USER.  

ERROR 200-322: The symbol is not recognized and will be ignored.

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

daily — Thu, 06 Jul 2017 11:46:39 GMT

Hi patrick ,

first thanks for quick replay .

which you have given code i submitted and getting below issue.

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

Kurt_Bremser — Thu, 06 Jul 2017 11:52:18 GMT

@Patrick wrote:

@Kurt_Bremser

I guess that happened because the OP copied the code first into MS WORD or the like. But such quotes would create a syntax Error and not the Error the OP posted.

27         proc sql;
28           select *
29           from DICTIONARY.TABLES
30             where libname = ”WORK”;
                               _
                               22
                               200
ERROR 22-322: Syntax error, expecting one of the following: a name, a quoted string, a numeric constant, a datetime constant, 
              a missing value, (, *, +, -, ALL, ANY, BTRIM, CALCULATED, CASE, INPUT, PUT, SELECT, SOME, SUBSTRING, TRANSLATE, 
              USER.  

ERROR 200-322: The symbol is not recognized and will be ignored.

Have to differ.

Just tried that exact code from EG 7.1 to SAS 9.4 on AIX, and got exactly the error message from EG (not SAS, mind!) that the OP reported.

Edit: the code never really reaches the SAS session, as Integration Technologies coughs up while trying to transmit the code. Did you run the code from Studio or DM?

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

Patrick — Thu, 06 Jul 2017 11:53:57 GMT

@Kurt_Bremser

What I've posted has been run in EG 7.13 HF5 (7.100.3.5486) (64-bit) against a local SAS under Win7.

@daily

Just to re-test, can you please do the following:

1. Re-connect to your server so that you get a clean new SAS Session

2. Run the following code and let us know the outcome.

proc sql;
  select 
    libname 
  from DICTIONARY.TABLES
    WHERE UPCASE(LIBNAME)="CRM_ANAL";
quit;

Re: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE

Kurt_Bremser — Thu, 06 Jul 2017 11:54:02 GMT

@Patrick wrote:

@Kurt_Bremser

What I've posted has been run in 7.13 HF5 (7.100.3.5486) (64-bit) agains a local SAS.

Then Integration Technologies does not come into play. It's the quotes, I bet you a can of Ottakringer on that.