Yes, I know. I think it was introduced in v6 but it simplified the variable creation a lot and initializes the PDV. It doesn't do anything different but it puts the variable info in one place and is easier to read.   Here is statement on my Tips/Tricks on GitHub: savian-net/SasTipsTricks: Tips and tricks learned over 20+ years as a SAS/Microsoft consultant (github.com)   When I was a SAS consultant, I left the client's with a variation of that Tips/Tricks document...at every client. I 'think' it was best practice to use ATTRIB in SAS Consulting but not sure (too many years). Here is sample code:   libname temp 'x:\temp'; data temp.temp (drop=i); attrib AA1 label="Var1" AA2 label="Var2" AA3 label="Var3" length=$10 format=$7. informat=$9. AA4 label="Var4" length=$10 AA5 label="Var5" length=$10 AA6 label="Var6" length=$10 AA7 label="Var7" length=$10 AA8 label="Var8" length=$10 AA9 label="Var9" ; do i = 1 to 10; aa1 = 1 ; aa2 = 2; aa3 = "Test_" || put(i,z4.); aa4 = "Test2" ; aa5 = "Test3" ; aa6 = "Test4" ; aa7 = "Test5" ; aa8 = "Test6" ; aa9 = 12 ; output ; end; run;     ... View more

The attrib, introduced later, handles all aspects for the pdv including length, format, informat, and label. Hope that clears it up. ... View more

See my example on my tips and tricks page: https://github.com/savian-net/SasTipsTricks#use-a-dataset-as-a-lookup-in-another-dataset ... View more

Always, ALWAYS, start a data step with an attrib statement describing each variable. Do not use the old means of handling it like length function. The attrib will create the variable for you exactly as you want it. ... View more

VBS is very deprecated. Do not use it for anything. PowerShell is a much better option if you go that route and it is easier to use. A custom task is the best but it requires some C# coding.    Too often, the idea is to do everything in SAS. As a Microsoft product, you can do much, much more in C# with Excel than you can in SAS. SAS is great at doing the ETL but then let the base technologies take over.   If you want 100% control for Excel, consider the custom task. If you only need some level of control, PowerShell can afford that. C# sits on .NET, EG is coded in .NET, and PowerShell is .NET: VBS/VBA/etc. are not. VBA and VBS were deprecated over a decade ago.    I am like the bearer of bad news on this thread: sorry. I have built numerous custom tasks in EG and am converting 42K lines of VBA code to C# right now. The custom task is actually not bad just read about interfaces and how they work. Create a WPF project in Visual Studio (free) and implement the SAS interfaces. From there, create a simple app with as many dropdowns, lists, comboboxes, etc. that you wish. Visual Studio will actually implement the whole interface for you so there is no need to dig around looking for how to do it.    ... View more

Sorry, that is not true. EG is a C# app and interfaces with SAS using Integration Technoloies. You can create any UI elements using a custom task. Plenty of papers on it. You should use WPF. This requires C# development but there are lots of examples. ... View more

As mentioned, SAS is not the best way to handle. Typing on cell so apologies in advance. SAS datatsets are ODBC compliant. Download free driver from SAS but it is probably already installed. Use something like PowerBI to read SAS data and format the report. Any report writer can read odbc. ... View more

While Studio is nice, it isn't as fast on startup and isn't as responsive. That was my take. I had a client where everyone had Studio and EG and the analysts all left Studio due to speed issues. They stuck with EG.   I am unsure on Viya adoption. If a client is staying with SAS 9.4, w/o Viya, EG works fine. In many cases, where EG doesn't do everything, you can build a custom EG Add-In and fill in the gaps. I have built numerous EG Add-Ins and they work fine. You can't do everything but they can help close gaps.  ... View more

My favorites in EG are code formatting and intellisense. I still like DMS too. DMS is more bare metal and direct.  ... View more

The SAS dev team determined that the best way to work with SAS on a server was using ,NET. That was 20 years ago. .NET is now way, way more functional and covers all operating systems. The sooner you manage SAS using .NET (C#), the better.    Your world with SAS will change once you move to a managed infrastructure with modern tech. I 100% get that it isn't easy right now but please make it a priority. I am happy to help, gratis, to aid you in the direction you need. Reach out to me on github and I will throw a project or two to help get you on the way.   ... View more

A very, very easy way of handling this is via RPA. Power Automate, free with Windows, and simply record the action, like a macro in Excel. ... View more

If you want to control EG, or do what it does, look up my github code and do what you need to do. EG is great for people that do clicky-clicky. It is a fantastic program. I code and dont need that. Everything in EG is doable w/o EG. Use IntTech, call SAS server directly and bypass EG. If you need to read existing code fr an EG project, you can do that. It is all in XML. However, you need to use c#. I am happy to help if you get the infrastructure ready. I can send code samples as needed. ... View more

EG is a C# based platform. It is both possible to read the egp file, pull out the relevant steps, and execute them using integration technologies. Do you need EG? Not technically, but practically, yes. My only point is absolutism. It is both posdible to execute the code elements within the EG project and get the results by essentially mimicking what EG does using .net code and call it via an X command. However, it is much easier to do it using EG. I will show a bit of the EG unwinding at SESUG. ... View more

I rely on nuget in the .NET world. SAS needs something along those lines. Highly agree with Bart here. ... View more

Check your Windows disability settings. ... View more