Error While Downloading A CSV File To A SAS Dataset Using The "Proc Download" Statement in SAS Viya

[NarutoDP]

Hi All,

I am using the ""Proc Download" Statement in SAS Viya to download a CSV file as a SAS dataset.

I get an error saying: "Download function terminated. The file created may be unstable".

On analysis, I found that it is unable to parse/decode a double hyphen character from the csv file.

Can you pls suggest an option wherein I can force download the csv file or replace that character while downloading.

Thank You....

[Tom]

Did VIYA introduce a new PROC DOWNLOAD?

Otherwise I cannot figure out what you actually did.

PROC DOWNLOAD can be used to move files between a remote SAS session you started with SAS/Connect. 

It can move datasets or files (like a CSV). 

But it has nothing to do with converting a text file, like a CSV file, into a dataset.

[NarutoDP]

Thanks for the reply.

I did not say that I am converting. I said, am downloading a csv file.  

[Tom]

You are the one that said you were making a SAS dataset.

You can use PROC DOWNLOAD to copy a FILE to a FILE.

Did you use the BINARY option on PROC DOWNLOAD?

Otherwise what encoding is being used? In both SAS sessions?

[NarutoDP]

I am not sure what you are reading and understanding.....anyways.....

I think we all know what Proc Download is used for....

I have not used the Binary option.

UTF-8 and Latin1 are the encodings used. 

[Tom]

Not all valid UTF-8 characters can be mapped in the limited 256 positions of a single byte encoding like LATIN1.

So either fix the file before downloading it to only contain valid LATIN1 characters.

Or download the file as BINARY and deal with the transcoding on the other side.

[NarutoDP]

Downloading file has latin1 encoding and my session has UTF-8 encoding.

So, would downloading the file as Binary work for the above also.

Thanks for your quick response.

[Tom]

---

@NarutoDP wrote:

Downloading file has latin1 encoding and my session has UTF-8 encoding.

So, would downloading the file as Binary work for the above also.

Thanks for your quick response.

---

Yes, since it will not try to transcode a binary file.

The only reason why a UTF-8 session would have trouble reading a LATIN1 file would be if it treated the file as UTF-8 and the sequence of bytes was something that was invalid as a UTF-8 character.  So you might need to use the ENCODING= option on the INFILE statement that reads the file once you have it copied.

[NarutoDP]

When I use the Binary option, it throws a warning first and then an error as follows:

Warning: A character that cannot be transcoded was encountered.

Error: An exception has been encountered.

Error: File ....... does not exist.

[Kurt_Bremser]

When using binary correctly, no transcoding is done. The file is treated as a stream of bytes.

So it seems you use this incorrectly. Please post the complete (all code and messages) log of your code, including all FILENAME definitions used in the DOWNLOAD procedure.

Copy/paste the log text into a window opened with this button:

Edit sensitive parts after the paste.

Partial logs are not helpful, as messages must be viewed in their context.

[NarutoDP]

When I specify the binary option, as I have posted for another answer, the error is as below:

Warning: A character that cannot be transcoded was encountered.

Error: Invalid Data Length --- Sorry, had missed this one out...........

Error: An exception has been encountered.

Error: File ....... does not exist.

Code: rsubmit; proc download infile = file1 outfile = file2 binary; run; endrsubmit;

Sorry, cannot paste the whole code/log.

Thank You.

[Tom]

That is not what a SAS log looks like.  The log should include the code and the messages in context.

I am trying to tell if there is some issue with the PROC DOWNLOAD syntax or if the transcoding is being caused by something that is VIYA specific, perhaps in the FILENAME statement you did not show.

Here is an example of a SAS log using PROC DOWNLOAD to copy a BINARY file.

798  filename local temp;
799  rsubmit;
NOTE: Remote submit to REMOTE1 commencing.
7      filename remote 'c:\downloads\tables.xlsx';
8      proc download infile=remote outfile=local binary;
9      run;


NOTE: BINARY download in progress from infile=REMOTE to outfile=LOCAL
NOTE: The file LOCAL is file C:\Users\xxx\AppData\Local\Temp\1\SAS Temporary Files\_TD17752_AMRAPY3WVP0VKU0_\#LN00052.
NOTE: Downloaded 49 records and 12523 bytes.
NOTE: 12523 bytes were transferred at 245549 bytes/second.
NOTE: 49 records were written to the file C:\Users\xxx\AppData\Local\Temp\1\SAS Temporary
      Files\_TD17752_AMRAPY3WVP0VKU0_\#LN00052.
      The maximum record length was 256.
      The minimum record length was 235.
NOTE: PROCEDURE DOWNLOAD used (Total process time):
      real time           0.07 seconds
      cpu time            0.00 seconds


NOTE: Remote submit to REMOTE1 complete.

[Kurt_Bremser]

Please read my post again, particularly the complete part.

PARTIAL LOGS ARE NOT HELPFUL.

[NarutoDP]

I do acknowledge the fact that partial logs are not helpful. 

I have been consistently apologizing and stating that I cannot share the complete code or the complete log.

I hope you have taken note of that. 

Thank you for your responses.

[Patrick]

---

@NarutoDP wrote:

I do acknowledge the fact that partial logs are not helpful. 

I have been consistently apologizing and stating that I cannot share the complete code or the complete log.

I hope you have taken note of that. 

Thank you for your responses.

---

Then you need to narrow down your code so it still shows the issue without disclosing confidential information. This should be possible for a Proc Download. Alternatively and/or complementary you can also post-process the SAS log manually to remove any confidential PII information like IP addresses, credentials, server names etc.

Without the full (or almost full) log it's really close to impossible to determine why something isn't working as you state even though it should (as Tom demonstrated for a binary download).

If sharing the log is really not possible then I suggest you contact SAS Tech Support where you can disclose more information as it's not public.