Hi @Sonali4! 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 ... View more

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. ... View more

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. ... View more

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. ... View more

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 ... View more

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 ... View more