Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Header record of a pipe-delimited file not ready when suspected special character exists. #1368

Closed
SundareshSankaran opened this issue Jan 13, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@SundareshSankaran
Copy link

Describe the bug
Upon running the following proc import statement, I get a successful import, but getnames=Yes is not honoured.

Upon running the same code in SAS Studio, I notice that the first header seems to have a special character (undetectable in text editor).

Output from VS Code extension:
Screenshot 2025-01-13 at 1 42 10 pm

Output in SAS Studio:

Screenshot 2025-01-13 at 1 43 10 pm

Steps to reproduce
Steps to reproduce the behavior:

  1. Open SAS editor / file

  2. Run code:

/* Import Visit Info  */

proc import datafile="/mnt/viya-share/data/Patient_Data/data/VisitInfo_a.txt"
   out=WORK.PATIENT_DATA
   dbms=dlm
   replace;
   delimiter="|";
   getnames=yes;
run;

proc print data=_last_;
run;

Data snippet can be shared internally (sundaresh.sankaran@sas.com)

Expected behavior

Header records are read and displayed in VS Code results window.

Screenshots
Attached

Environment (please complete the following information):
Client OS: Mac 15.2 Seqouia
Extension version: 1.13.0
SAS version: Viya Stable 2024.12

@SundareshSankaran SundareshSankaran added the bug Something isn't working label Jan 13, 2025
@snlwih
Copy link
Collaborator

snlwih commented Jan 14, 2025

@SundareshSankaran, doesn't seem to be a bug in VSCode. Are you sure the SAS Extension and SAS Studio are using the exact same configured SAS Compute? Could it be that they are using different compute environments with different configuration settings (encoding maybe?), causing the same proc import code to generate different results?

@SundareshSankaran
Copy link
Author

Thanks, @snlwih , as mentioned offline, the issue was due to the encoding of the source file, which was in UTF-16 LE. I used a filename statement similar to this which solves the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants