About CaseySmith

CaseySmith · ‎05-25-2018

I wanted to add... I suspect you are using 64-bit EG. EG uses the Microsoft Jet Engine provider to write to the .mdb format. The Microsoft Jet Engine is 32-bit only, thus only works in 32-bit EG, thus exporting to .mdb (via the client UI) is only available in 32-bit EG. EG's system requirements doc has this note: "Note: On 64-bit operating systems, SAS recommends using the 32-bit version of SAS Enterprise Guide for greater compatibility with data providers. See reference, SAS Deployment Wizard and SAS Deployment Manager 9.4 User's Guide.pdf for more information." Related, but applies to import rather than export... in the EG help (Help->SAS Enterprise Guide Help), the "Working with Data: File types that SAS Enterprise Guide reads and writes" topic has this note: "In the 64-bit version of SAS Enterprise Guide, you can import Microsoft Access files (*.mdb, *.accdb) only if the 64-bit version of Microsoft Access or the 64-bit version of the Microsoft Office System (ACE) Driver is installed. Similarly, if you are running the 32-bit version of SAS Enterprise Guide, then you must have the 32-bit version of Microsoft Access or the Microsoft Office System (ACE) Driver in order to import Microsoft Access files." Note: The comments above apply to the client, when the client is performing the import or export (rather than SAS code on the server). The server (ex. processing proc import and proc export) has different, but similar requirements. See proc import/export doc for those. Casey

CaseySmith · ‎05-23-2018

I suggest following the recommendations in Usage Note 58761. The specific root problem in that note is specific to Windows 10, but the resolution steps apply to any Windows version with same symptom (inability to connect to Local server). Specifically, open your local Base SAS first (sounds like you already did), check your setinit/license to make sure it is current (though you wouldn't be able to open Base SAS if it wasn't), see if you are able to connect to the Local server using the SAS Integration Technologies Configuration Wizard, and see if re-registering your local SAS resolves the issue (instructions for both are in that Usage Note). Casey

CaseySmith · ‎05-22-2018

We are targeting Q2 2019, but I obviously can't promise anything. Casey

CaseySmith · ‎05-21-2018

In the next release of EG (EG 8), you'll be able to organize views within the EG application window however you would like *and* float any views out into separate windows to leverage multiple monitors. For example, you could view 6 (or more, up to you) data sets (or programs, or any other view) at one time in the EG application window, or you could drag each out into its own window and organize them however you desire across however many monitors you have. You'll be able to layout code, log, ODS results, and output data however you like; for example, you could view all four at the same time. Creating a fully flexible windowing environment for SAS programming is one of our primary goals for this next EG release. Casey

CaseySmith · ‎05-18-2018

I confirmed this issue was fixed in EG 7.13. Note: The "WHERE" clause filtering feature was added in EG 7.11. Casey

CaseySmith · ‎05-09-2018

This issue was fixed in EG 7.13 and 7.12 HF6. The slowness was a result of the time it was taking to setup the "file change notification" feature for all the external files. We resolved by moving this work to a background thread. Casey

CaseySmith · ‎05-09-2018

Hi @Viraaj, The first thing I would check is the network latency between the client machine (where EG is running) and the server machine (where the SAS server is running). If those two are geographically distant or in an otherwise high network latency environment, you can experience sluggish performance. For environments such as this, we typically recommend presentation virtualization, such as Citrix, as a way to reduce the latency between the client and server. The second thing I would check is your SAS Workspace server logs to see if the server itself is sluggish. Otherwise, I suggest contacting SAS Technical Support. Casey

CaseySmith · ‎05-09-2018

That is odd. I have tried to reproduce with 7.12, 7.13, and 7.15 without success. You could try closing the Log Summary view to see if that has anything to do with it, but that is a shot in the dark. Does it happen with simple programs (ex. "%put &sysvlong;")? Does it happen only when large logs are generated? What is the code doing (ex. creating ODS results, creating output data, querying database)? Yes, please contact SAS Tech Support. We will need more information. Casey

CaseySmith · ‎05-09-2018

You might want to look into exporting all the code in your EG project (File->Export->Export All Code...), to see if that could meet your needs. It will export all the programs (both embedded and externally referenced) in your project to a single .sas file. If your programs are stored as .sas files (rather than embedded in EG projects), I'd suggest using an operating system command to concatenate them together. For example, the cat command if using Linux (ex. cat 1.sas 2.sas 3.sas > combined.sas) Casey

CaseySmith · ‎05-04-2018

Sorry for the late reply. Using EG's automation interface (scripting with VBScript or Windows Powershell) is going to be your best bet. I posted some example VBScript code in this post, that will allow you to execute whichever process flows in whichever order you would like: https://communities.sas.com/t5/SAS-Enterprise-Guide/execution-Order-of-process-flow-in-a-project-using-Windows/m-p/460147#M29672 Note: The easiest way to create a stock EGScript1.vbs file is to schedule your project (File->Schedule Project in EG). That will create the EGScript1.vbs file for you in the same directory as your project. (You can immediately delete the scheduled task EG creates in Windows Task Scheduler, unless you actually want it run on a schedule.) Then you can open and edit the EGScript1.vbs file as desired and run it from command line. (Make sure your EG project is not open when you run the VBScript file.) Casey

CaseySmith · ‎05-04-2018

Yes, you can change the order. By default, when you schedule a project, the whole project is run (in its default order). For example, if you look at the EGScript1.vbs (the VBScript file created by EG that Windows Task Scheduler runs to execute your project), in it you'll see where the whole project is run: '----- ' run the project '----- prjObject.run If Checkerror("Project.run") = True Then Exit Sub End If Instead of using that code, you can replace it with code that gets the desired process flows from the project's ContainerCollection and run them in whatever order you desire. For example: prjObject.ContainerCollection.Item("Process Flow 2").Run prjObject.ContainerCollection.Item("Process Flow 1").Run Casey

CaseySmith · ‎05-01-2018

Two things I would check: Check in Windows Task Manager to see if there is another unexpected seguide.exe (or if you were scheduling, wscript.exe or cscript.exe) process hanging around. Your .egp file may have a lock held open as a result of still being accessed by one of these processes that did not terminate properly. If you don't have any EG windows open and no Windows task scheduler jobs running, then you shouldn't see any seguide.exe, wscript.exe, or cscript.exe processes running. If you do, and confident they shouldn't be there, you can kill those processes (or restart your computer). Another option is to use a utility that will identify processes that are locking files, so you can see exactly what process is accessing your .egp file. Check the file permissions on the .egp file to make sure you have write access on the file. The first one is much more likely. Casey

CaseySmith · ‎05-01-2018

Thanks for clarifying. No, it does not change my response. It is perfectly fine to have SAS 9.2 for Windows and SAS Add-in for Microsoft Office 7.1+ (from 9.4M+ orders) on the same machine (they should work fine together). 7.1x versions of the SAS Add-in for Microsoft Office will work with any SAS server version 9.2 or later, whether installed locally (on the same machine as the SAS Add-in for Microsoft Office plug-in) or remotely (on a separate server host). Note: The only problem I can think of that you might run into is this one, if you don't have the latest 9.2 hotfixes applied: http://support.sas.com/kb/40/596.html It is easily addressable by installing the 9.2 hotfix linked in that SAS Note. Casey

CaseySmith · ‎04-27-2018

Hi @Bunz, Yes, you should use the same libname statement in both profiles to assign a library to the same data source (your large table). It is not necessary (and would be very inefficient and cumbersome) to have to recreate the data for each profile. Casey

CaseySmith · ‎04-26-2018

Yes, the SAS Add-In for Microsoft Office 7.1x supports SAS 9.2 and later... In Additional Requirement Information section at link below... "Note: SAS Add-In 7.1 for Microsoft Office supports SAS 9.2, SAS 9.3 and SAS 9.4." http://support.sas.com/documentation/installcenter/en/ikmsofficeintsr/68008/PDF/default/sreq.pdf Casey

Online Status	Offline
Date Last Visited	‎10-09-2025 07:58 AM