When you read in a BigQuery table, all the variables for a row might be missing when the following is true:

• The SAS^® encoding is Latin.
• One of the string columns contains a character that causes a transcoding issue. This issue occurs because the string column contains at least one Unicode character that is not supported with Latin encoding.
• You use the READ_MODE=STORAGE option. Or, if you do not have the READ_MODE=STORAGE option, you also do not have the BULKUNLOAD=YES option.
• You use the READBUFF=1 option, or the autoguess readbuff that is chosen by the SAS/ACCESS^® product is not equal to 1.

Note: In some instances, indications in the SAS log about a transcoding issue might not occur.  

Warning and Error Messages

Here are some messages that might occur as a result of this issue.

If you use a DATA step, a warning similar to the following might occur:

If you use READBUFF=1, an error similar to the following might occur. In addition, the step stops processing.

Note that, if you use the BULKUNLOAD=YES option without the READ_MODE=STORAGE option, there might also be no indication of a problem. Rather than the variable being missing, an extra character (Â) occurs in front of the character that could not be transcoded. The other variables contain the values that existed in the database. Only the variable with the transcoding issue is different.

Workaround

The only workaround for this issue is to use UTF-8 SAS.

After the applying the hot fix, you can now specify an environment variable that will allow you to replace a variable with a character that you supply.  It can be set during the execution of the program using an OPTIONS statement:

Operating System and Release Information

A fix for this issue for SAS/ACCESS Interface to Google BigQuery 9.43 is available at: