CaseySmith Tracker

Re: Help needed: importing flows via API in SAS Viya 4

CaseySmith — Fri, 22 May 2026 19:25:07 GMT

Thank you for your questions. I assume you mean flows in SAS Studio, but if you meant something else (like Job Flows in Environment Manager), please let us know. I was also a little unsure of whether you truly meant "importing" (the word you used in the title) an existing SAS Studio flow or creating a flow from scratch using an API, but no worries -- I'll try to answer both...

Currently, there are no public APIs for creating a SAS Studio flow from scratch. Rather, SAS Studio uses an internal dataFlows service for working with flows. The only related public API is SAS Studio Development, which currently only has one endpoint for generating the code that Studio would run for a program or a flow.

We are working toward exposing more SAS Studio capabilities programmatically, including flow building, which will eventually also be able to be driven by AI agents. But in the meantime, if you want to programmatically create a flow, though not an official recommendation, your best bet for now is to manually build one flow in SAS Studio, download it as a .flw file, inspect the json format inside of it, then write code to generate desired .flw files in the same format.

If you were wanting to automate "importing" existing flows into SAS Studio, if you plan to store the .flw files in SAS Server, you don't really need to import them at all. Rather, you just move the .flw files to mounted storage which is accessible to your Viya 4 deployment. Then in SAS Studio, the flow (.flw) files will appear in the mount under SAS Server and you can open, edit, and run them from there. If you are wanting to store them in SAS Content, there is an additional step needed to register them in the dataFlow service. SAS Studio performs this step for you when you manually upload a .flw file to SAS Content in SAS Studio. Again though, the dataFlow service is not a public API.

Hope this helps.

Casey

Re: SAS Enterprise Guide 7.15 crashing when running selected items in a script

CaseySmith — Thu, 09 Oct 2025 12:15:16 GMT

There is a SAS Problem Note which documents this issue:
https://support.sas.com/kb/61/144.html

It will be updated when/if an EG hotfix is available.

Re: SAS Enterprise Guide 7.15 crashing when running selected items in a script

CaseySmith — Thu, 09 Oct 2025 12:10:45 GMT

Though this is an old thread, I wanted to share a couple updates...

While Microsoft fixed the root issue for Windows SKUs (Windows 10/11) back in 2018, they did not make the same fix in Windows Server SKUs. Therefore, this problem still reproduces in Windows Server versions (when used with touch-enabled screens).
We are currently working with Microsoft to come up with code changes in EG that allow us to avoid the access violation in the Microsoft dll. We are hopeful that we will be able to release these changes in an upcoming EG hotfix, thereby addressing this issue in Windows Server versions as well.

Casey

Re: EG 8.3 does not show updates (e.g. to 8.4)

CaseySmith — Thu, 06 Feb 2025 22:31:07 GMT

This is an old thread, but will respond in case anyone else comes across it in a search...

This is a known issue, documented in SAS Problem Note 66889 here: https://support.sas.com/kb/66/889.html

(Problem Note 66889: The "Check for Updates" process does not notify you about updates in the 8.3 version of SAS® Enterprise Guide® and SAS® Add-In for Microsoft Office)

In short, if you have EG 8.3 with no updates (8.3.0.103), you will have to use the traditional way (SAS Deployment Manager) to install a newer 8.3 hotfix one time. After that, Check for Updates should work again.

Re: VS Code and SAS 9.4 - Connection does not support SAS content navigation

CaseySmith — Fri, 09 Feb 2024 13:00:28 GMT

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

Re: SingleStore binary(32) datatype shows values A2A2A2A2A2A2... in SAS Enterprise Guide using ODBC

CaseySmith — Sat, 04 Mar 2023 07:35:37 GMT

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.

Re: SingleStore binary(32) datatype shows values A2A2A2A2A2A2... in SAS Enterprise Guide using ODBC

CaseySmith — Thu, 16 Feb 2023 16:09:00 GMT

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.

Re: SingleStore binary(32) datatype shows values A2A2A2A2A2A2... in SAS Enterprise Guide using ODBC

CaseySmith — Fri, 10 Feb 2023 02:36:59 GMT

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

Re: SingleStore binary(32) datatype shows values A2A2A2A2A2A2... in SAS Enterprise Guide using ODBC

CaseySmith — Thu, 09 Feb 2023 06:08:17 GMT

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

Re: Update from Enterprise Guide 8.1 to 8.2 failing

CaseySmith — Thu, 08 Oct 2020 05:26:40 GMT

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

Re: "Preparing server" message with EG

CaseySmith — Thu, 10 Sep 2020 15:00:59 GMT

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

Re: SAS EG Can Find Local Server But Cannot Connect To It

CaseySmith — Sat, 22 Aug 2020 01:45:38 GMT

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

Casey

Re: SAS EG Can Find Local Server But Cannot Connect To It

CaseySmith — Fri, 21 Aug 2020 20:23:17 GMT

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

Re: "Preparing server" message with EG

CaseySmith — Fri, 21 Aug 2020 20:05:03 GMT

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

Re: Lost write priveleges when upgraded to SAS EG 8.2 (ODBC Connect SQL database)

CaseySmith — Fri, 21 Aug 2020 19:26:11 GMT

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

Casey

Re: Lost write priveleges when upgraded to SAS EG 8.2 (ODBC Connect SQL database)

CaseySmith — Wed, 19 Aug 2020 19:43:38 GMT

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

Re: Parallel Processing in SAS EG generates Libref is not assigned error

CaseySmith — Sat, 15 Aug 2020 22:27:24 GMT

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

Re: SAS EG options configuration file

CaseySmith — Sat, 15 Aug 2020 21:56:37 GMT

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

Re: SAS Guide 8.2 : Windows "Open file have been modified by an external editor"

CaseySmith — Sat, 15 Aug 2020 21:11:37 GMT

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

Re: SAS Enterprise Guide 8.2 Update 2 - Server Library List Problem

CaseySmith — Sat, 15 Aug 2020 20:55:07 GMT

Just for clarification, the potential for high memory consumption (when fully expanding libraries with lots of tables by clicking the "More" or "All" links in the Servers pane) was introduced in EG 8.1. It existed prior to EG 8.2 Update 4. As mentioned in the linked thread, the recommended workaround is to use the File Open dialog for navigating items beyond the first 500, rather than using the "More" and "All" links in the Servers pane.

Casey