About CaseySmith

CaseySmith · ‎09-27-2017

A few other minor things that weren't listed: You can now perform Project Log operations (enable/disable, retrieve the text, clear, save as, send via email) via automation. This can be handy if you want to avoid your Project Log from filling up. For example, you could use a VBScript to periodically write the project log to a file, then clear it. Though we hope to build this functionality in more natively in a later release. In Query Builder, you can now move selected variables to the top or bottom of the list (rather than up or down one position at a time). Role metadata capabilities were added for the Excel and PowerPoint results formats and for the Copy Files task. As with most releases, also includes a number of bug fixes.

CaseySmith · ‎09-20-2017

From the callstack above and inspecting our code, it appears that the SDSControl.xml file in your %appdata%\SAS\SharedSettings\v.v location (ex. C:\Users\<userid>\AppData\Roaming\SAS\SharedSettings\4.3\SDSControl.xml) file does not contain valid xml. You can safely delete that SDSControl.xml file (it will be regenerated), which should resolve the issue.

CaseySmith · ‎09-12-2017

Yeah, if you aren't able to connect to the server using the "C:\Program Files\SASHome\x86\Integration Technologies\ITConfig2.exe" utility, you won't be able to connect to it from EG either (since EG uses the same underlying technology to communicate with SAS servers... Integration Technologies). As you mentioned, yes, it does appear to be an issue with the non-standard character (LATIN SMALL LETTER R WITH CARON) in the username. That character is C5 99 in UTF8, but the "failed to transcode" error message you shared shows it as "f8" (I don't currently have an explanation for that). You may need to change the session encoding of your locally registered COM server (Local) to an encoding that supports that character. One of my colleagues just pointed out it looks like you might be using this encoding... (Latin-2) https://en.wikipedia.org/wiki/ISO/IEC_8859-2, since it uses F8 for that character.

CaseySmith · ‎09-11-2017

We addressed this issue as a direct result of this thread, so thank you! In EG 7.11, we fixed the issue where the message was incorrectly displayed when saving the project. In EG 7.12, we added a "Do not show this dialog again" checkbox, so you don't have to see it again... So, @GabrielAzuar, upgrading to EG 7.12 or later will allow you to avoid the message. Casey

CaseySmith · ‎09-06-2017

Dean, I'm glad to hear that resolved your issue! Casey

CaseySmith · ‎09-05-2017

I suspect the difference is the way in which the EG project files are being accessed. If they are accessed through the local file system (which includes UNC paths), there will be a file system write lock on the file, thus additional people who open will only be able to open it "read-only" (what Tom is seeing). Whereas, if the EG projects are accessed through the SAS server (ex. SASApp->Files), there is no file system write lock, so no realization that another user currently has it open. I suspect this latter case is what you are running into. We are working on handling this scenario better in a future release.

CaseySmith · ‎09-01-2017

Chris is correct. And yes, we do have plans to add support for this scenario in a future release.

CaseySmith · ‎08-31-2017

It looks like the Path.GetTempFileName method call is failing on your computer. If you follow that link you'll see a possible cause for this: The GetTempFileName method will raise an IOException if it is used to create more than 65535 files without deleting previous temporary files. The GetTempFileName method will raise an IOException if no unique temporary file name is available. To resolve this error, delete all unneeded temporary files. So, try cleaning up the temporary files in your user temp directory. (Make sure you cleanup the temp files for the user that the scheduled task is running as.) (Type %temp% in the path field of Windows Explorer and press Enter to quickly navigate to the user temp directory for the currently logged in user.)

CaseySmith · ‎08-17-2017

Your libname statement indicates you are using the BASE engine. Another way to check is to query the dictionary table, with code such as: proc sql; select * from sashelp.vlibnam where libname eq "DBADG"; quit; I can't think of why you would be unable to edit the data grid values then. BASE engine is definitely supported. Try submitting this code: LIBNAME dbadg BASE "F:\SAS\Contexts\DBA\DataGrids"; data dbadg.test; set sashelp.class; run; After submitting that code, are you able to edit the values in dbadg.test that will be open in the data grid? EG 7.11 (7.100.1.2711) is the initial 7.11 release without any updates applied. You could try installing the latest update to see if you are encountering an issue that was addressed in an update: http://ftp.sas.com/techsup/download/hotfix/HF2/U23.html#U23005 Casey

CaseySmith · ‎08-17-2017

As @Kurt_Bremser indicated, opening the .egp file in a Zip application should allow you to recover code embedded in the project if the file is still reasonably intact. I suggest contacting Tech Support as well. Also, it is a good idea to make sure you have the latest update, in case you are encountering an issue that has already been addressed. Casey

CaseySmith · ‎08-17-2017

Sure, no problem. Yes, that is what I mean.

CaseySmith · ‎08-16-2017

Hi Laurent, Many other customers operate this way as well (support one version of the product for their end-users and roll-out updates to everyone at once to make sure they stay at same level). Yes, you can still update EG the traditional way (using SAS Deployment Manager) instead of using Check for Updates. You can also disable Check for Updates to prevent end-users from updating their EG clients via that feature. Casey

CaseySmith · ‎08-16-2017

What libname engine is your library assigned with? And what specific version of EG (in Help->About) are you using?

CaseySmith · ‎08-15-2017

Yes, SAS Studio will have the same issue, for the same reason.

CaseySmith · ‎08-15-2017

Hi @ScottBass, Yes, we are definitely aware of EG's inability to stop certain running jobs. I'm sorry for the inconvenience it causes. I know it is a pain -- it really annoys me too! Though it will not alleviate your pain, I can tell you the reason for this is on the server side. EG attempts to cancel the current job being run by the SAS server's language service, however the SAS server is busy (running the job) and for one reason or another (ex. perhaps waiting on DBMS response, disk IO, etc.) cannot be interrupted by the client. The client's cancel request falls on deaf ears, or at least cannot currently be executed by the server. We are working on improvements in a future EG release to handle this scenario more gracefully on the client side. For example, we are considering giving users the ability to abandon an "unstoppable" and/or unresponsive workspace session (since we know there are periods the server cannot be interrupted), so they can at least easily spawn a new session without having to close or kill EG. Casey

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