About CaseySmith

CaseySmith · ‎02-09-2024

Hi @andreas_lds! Thanks for your interest in the SAS Extension for VS Code! The short answer is... not yet, but it is coming soon. The initial support for connecting to V9 servers via IOM (released in v1.6.0 last month) does not currently have support for a library explorer or data viewer (which are currently supported with Viya connections). However, those are our next two top priorities, which we are actively working on adding. Here are a couple issues in the GitHub project you can follow: https://github.com/sassoftware/vscode-sas-extension/issues/680 https://github.com/sassoftware/vscode-sas-extension/issues/347 (we probably need to consolidate those two) Casey

CaseySmith · ‎03-04-2023

I finally got back around to looking at this one again. I'm pretty sure this will do the trick, but it is still a workaround for the fact there is not true binary data support in the data access layer (RIO). If you set the following SAS system option (submit the following code) prior to opening the data, then the actual values should come back and appear in the EG data grid, instead of being masked with asterisks: options TRANSCODEACTION=MODIFY; However, you will then likely run into this secondary issue... binary values that contain x00 will be truncated at the first occurrence of x00, since it gets treated as a null string terminator. To workaround this, you can instruct EG to read the formatted values directly by setting the FormatValuesAsNeeded config option to false (add the line "<add key="FormatValuesAsNeeded" value="false" />" to the appSettings section of the SEGuide.exe.config file in the EG installation directory, as I noted earlier in this thread). Those two things together should get you pretty close to what you want, even though (again) it is a workaround.

CaseySmith · ‎02-16-2023

Sorry to hear that did not resolve the issue. The fact that you are getting asterisks now ("************") instead of "2A2A2A2A..." confirms that the config option is doing what was asked (to request formatted values from the data layer, rather than raw values), however in this scenario, the data layer is also returning asterisks for the formatted value. This issue is lower-level than EG, the client. EG is just rendering the values that come back from the data access layer. Will see if I can get some simple steps to reproduce and take a closer look to confirm, but I'm fairly confident I could reproduce with a test program outside of EG.

CaseySmith · ‎02-09-2023

The only possible side effect I can think of is that very wide data (tables with lots of columns) might take a little longer to display in the data grid, since all of the columns will be formatted rather than a smaller subset just-in-time. Unless you are using very wide data, I doubt you'll notice a difference in performance. Casey

CaseySmith · ‎02-09-2023

This is a known issue, due to a limitation of the underlying data access technology EG uses to read values and the way EG reads values by default. Specifically, that access layer is unable to return binary/hex raw values in certain scenarios -- it quietly (without error or exception) returns a bunch of asterisks ("******...") as the raw value for binary/hex values instead. EG reads values (by default) by requesting raw values from the data access layer and then explicitly formats values for a certain number of columns to improve performance viewing wide data. Therefore, when EG gets back "******..." as the raw value (and no exception/error), it has no reason to assume this is not the correct raw value. EG then explicitly formats that value with the $hex format. The hex value for asterisk character is 2A, so "******..." formatted as #hex becomes the formatted value "2A2A2A..." When we became aware of this issue with the data access layer, we did add a config option (named "FormatValuesAsNeeded") that will allow users to workaround. Setting that config option to false will allow users to explicitly turn off the explicit formatting of raw values and revert to getting the formatted values directly from the data access layer, which is able to provide the proper #hex formatted value. So, if you make this change in your SEGuide.exe.config file, I would expect the values to display as you desire/expect... In SEGuide.exe.config file in your EG installation directory, set "FormatValuesAsNeeded" to false, similar to: <appSettings> <add key="FormatValuesAsNeeded" value="false" /> </appSettings> Casey

CaseySmith · ‎10-08-2020

This is a known issue that impacts everyone attempting to use Check for Updates to update to 8.2 Update 5 or later from an 8.x version prior 8.2 Update 5. Yes, make sure you follow the instructions for the SAS Note @SASKiwi shared (https://support.sas.com/kb/66/676.html). It is very similar to the 7.1x SAS Note you followed (https://support.sas.com/kb/61/521.html) (in both cases, you need to manually download a new AutoUpdate.exe), but one applies to 7.1x and the other applies to 8.x. Once you have the updated AutoUpdate.exe for your EG (or AMO) version, the problem will no longer occur. Note: You can also get to the SAS Note by clicking the "Pre-requisite Required..." link in the EG 8.x Check for Updates dialog... Casey

CaseySmith · ‎09-10-2020

Glad that resolved your issue! That looks like the same issue I ran into recently and the same solution (in the paper I linked). Casey

CaseySmith · ‎08-21-2020

@cgates, glad to hear that worked! Yes, in that case, I would contact your IT support team to allow the necessary permissions. Casey

CaseySmith · ‎08-21-2020

You tried all the things I would have first recommended you try (and the things that resolve the vast majority of the times someone is unable to connect). If you can't connect to the local server using the Integration Technologies Configuration Wizard (C:\Program Files\SASHome\x86\Integration Technologies\ITConfig2.exe), then EG won't be able to connect to it either. So, I suspect it is either a Windows permissions issue (even if you are an admin, not everything necessarily runs as admin) or a SAS Integration Technologies Client issue. I recommend checking the exact version of your SAS Integration Technologies Client. You could also try re-installing SAS Integration Technologies Client, which sometimes resolves issues. Did you try explicitly running the Integration Technologies Configuration Wizard as an administrator (right-click ITConfig2.exe and select "Run as administrator"? If not, I'd try that too to see if it makes any difference. Casey

CaseySmith · ‎08-21-2020

Loading the system printers can slow down SAS server connections. You can avoid this by using the NOPRNGETLIST option. https://support.sas.com/kb/33/562.html https://communities.sas.com/t5/SAS-Procedures/slow-initialization/td-p/245136# https://communities.sas.com/t5/General-SAS-Programming/SAS-9-4-Very-slow-or-not-responding/td-p/425615/page/2 Granted, your locally registered SAS command should already be using the NOPRNGETLIST option. I recommend submitting the following code then checking the log to ensure the option is set to NOPRNGETLIST and not PRNGETLIST: proc options option=NOPRNGETLIST; run; If it is not set to NOPRNGETLIST, I'd definitely update your locally registered SAS command or .cfg to use that option, since there is a known performance penalty without it. If the option is already set to NOPRNGETLIST, then I'd try a local connection using the SAS Integration Technologies Configuration Wizard tool (C:\Program Files\SASHome\x86\Integration Technologies\ITConfig2.exe) (Test SAS Servers, Next, Next, change Connection Protocol to COM, click Test) and see how the time to make a connection from that tool compares with EG. If they are not roughly the same, it points to initialization code as a likely culprit. I found the solution for another server initialization slowdown I encountered recently in this paper: https://www.sas.com/content/dam/SAS/support/en/sas-global-forum-proceedings/2018/2003-2018.pdf In my specific case, it was the DNS resolution was taking a long time, which I confirmed and fixed with the steps in the section, "Addressing Issues with gethostbyaddress Calls in Virtual Machine Environments". That paper has several other possible culprits to explore, so I recommend checking it out. Casey

CaseySmith · ‎08-21-2020

I agree, it sounds related to the user-permissions set in your DBMS, unrelated to SAS or EG. Casey

CaseySmith · ‎08-19-2020

By "it does not load all tables", do you mean the tables do not appear in the Servers pane or file open dialog in EG? If so, first I recommend running this code to make sure the tables you expect to see in that library are in fact in the library from the server's point-of-view: proc sql; select * from sashelp.vtable where libname eq "MYDATA"; quit; If all the tables you expect to see are in the results from running that code, then it may be a display issue in EG 8.2. There were a couple bugs related to library and table population in the EG 8.2 Servers pane and file open dialog that were fixed in EG 8.2 Update 4. If you don't already have 8.2 Update 4 (check in Help->About), I *highly* recommend you install it. (You can install the latest update via Help->Check for updates or the more traditional SAS Deployment Manager method by downloading and install the update here: http://ftp.sas.com/techsup/download/hotfix/HF2/G5J.html) Casey

CaseySmith · ‎08-15-2020

Hi @fuatengin, The parallel processing feature in EG causes multiple workspace sessions to be launched to perform the independent work in parallel. This can be tricky when your downstream code relies on upstream code that makes state changes (ex. assigns libraries, defines macro variables, sets system options, etc.) to a workspace session For example, the code you put in your process flow named "autoexec" causes the libraries to be assigned and the macro variable defined on only one of the workspace sessions. Any additional workspace sessions that are spun up to perform work in parallel will not have those libraries or macro variables defined. If you don't explicitly define a dependency, there is no guarantee the upstream code you need will be run on the same workspace session as your downstream node. So, to ensure your "setup code" is run on the respective workspace sessions before each of your independent programs, I recommend adding a separate code node before each or your programs (rather than using the autoexec process flow) and explicitly linking your "setup" program nodes to your actual programs. (You'll want two "setup" code nodes to ensure the two branches remain independent/unconnected, so they'll run in parallel. However, they could both %include the same .sas file (so you only have one to maintain) to assign your libraries and define your macro variables.) Casey

CaseySmith · ‎08-15-2020

Hi Marc, The _CLIENTMACHINE macro variable is defined in the EG initialization code that is submitted by EG when a connection is first made to a workspace server. Therefore, you can use that macro variable in the "Submit SAS code when server is connected" option (in Tools->Options->SAS Programs), including to define your own macro variable that uses it. For example, I added this code to the "Submit SAS code when server is connected" option: %let myMacroVar=client machine: &_CLIENTMACHINE; Then, when I submit "%put &myMacroVar;" in a new EG session (which causes a new workspace connection), the new macro is resolved. That option is stored in the EGOptions.xml file stored in each user's appdata location (ex. %appdata%\SAS\EnterpriseGuide\8). Yes, it is stored in the xml element named "strOnServerConnectSASCode" in each user's EGOptions.xml file. (So, you'd have to edit all the user's EGOptions.xml file to add -- you'd probably want a script.) Yes, you could include code in that option to %include your .sas file to define your macro var. To see the server initialization log, where this code executes, right-click the server in the Servers pane (after you've connected to the server), select Properties, Software, then View Initialization Log. Casey

CaseySmith · ‎08-15-2020

What specific version of EG 8.2 do you have (in EG's->Help->About dialog)? I highly recommend applying the latest EG 8.2 update (currently Update 4... http://ftp.sas.com/techsup/download/hotfix/HF2/G5J.html#G5J004) if you don't already have it. It may or may not fix this specific issue, but there have been quite a few fixes since 8.2 was originally released. After ensuring you have the latest 8.2 update, the other thing I would check is whether the modified date of the file in question is being changed by an outside process. For example, in Windows File Explorer right-click the file and select Properties, then Details, and note the modified date. Next time the "file change notification" dialog appears, re-check the modified date and see if it in fact changed. Casey

Online Status	Offline
Date Last Visited	4 weeks ago