About CaseySmith

CaseySmith · ‎11-07-2017

We are aware of this scaling issue, which occurs when the DPI settings are greater than 100%. It is more pronounced (particularly the wide scrollbars) on higher resolution screens. We believe it is a side-effect of the mixing of Microsoft UI technologies (WPF and Winforms). It will be resolved in our next release. In the meantime... Though I'm sure it's not desirable with your high resolution, setting the DPI to 100% should avoid the scaling issue. Or at least reducing the DPI would make it less pronounced. A partial workaround for the editor is to change the font size (in Program->Editor Options->Appearance tab). Finally, you can use Ctrl+MouseWheel to zoom to a more comfortable viewing size. (Sorry for the inconvenience.) Casey

CaseySmith · ‎11-07-2017

Where is the project being opened from? 1. The local file system? (This includes remote shares via UNC paths.) 2. The SAS server file system? (ex. View->Servers->SASApp->Files) 3. View->SAS Folders?

CaseySmith · ‎10-31-2017

Terrence, Since you are able to edit the data when you manually assigned a library using the BASE engine and your DBADG library is configured to be assigned via the META libname engine (which can be seen in your query results), I suspect it is just a permissions issue. I suggest checking the permissions on your library (and/or registered tables) defined in metadata (using SAS Management Console). Casey

CaseySmith · ‎10-31-2017

Thanks for trying that out Peter. Yeah, Tech Support is probably the best route, so we can track it in our system. If we find a way to reproduce, we'll certainly investigate. Casey

CaseySmith · ‎10-30-2017

It sounds like you may be encountering an issue that was introduced with this recent (10/10/2017) Microsoft update: https://support.microsoft.com/en-us/help/4041691/windows-10-update-kb4041691 In the Known Issues section... Installing this update may cause applications based on the Microsoft JET Database Engine (Microsoft Access 2007 and older or non-Microsoft applications) to fail when creating or opening Microsoft Excel .xls files. The error message is, “Unexpected error from external database driver (1). (Microsoft JET Database Engine)". Download and install the Microsoft Access Database Engine 2010 Redistributable, and then modify the DB connection strings in Microsoft Excel to use ACE as a provider. Example: Change Provider=Microsoft.Jet.OLEDB.4.0 to Provider=Microsoft.ACE.OLEDB.12.0. Microsoft is working on a resolution and will provide an update in an upcoming release. (If you wish to confirm this is the issue, turn on EG logging (in Tools->Options->Application Logging), reproduce the problem, then search your EG log for the error message, "Unexpected error from external database driver".) Microsoft has not provided a resolution at this time. Also, EG users can't make use of the Microsoft suggested workaround (above), since the EG application would have to be changed to implement the workaround. We plan to contact Microsoft regarding this issue. For now, there are some workarounds in EG (ex. export to another format, such as xlsx, csv; use proc export, etc.). UPDATE: We contacted Microsoft. They pointed out the blog post below which contains more details, and indicated a fix is forthcoming in their November update: https://blogs.msdn.microsoft.com/dataaccesstechnologies/2017/10/18/unexpected-error-from-external-database-driver-1-microsoft-jet-database-engine-after-applying-october-security-updates/ Casey

CaseySmith · ‎10-30-2017

Hi Peter, I confirmed my editor option to color undefined keywords red (the default) is set. Also if I rename "format" to something incorrect like "forwat", it is properly colored red. If you type (or copy/paste) this into a new program in EG 7.15, do you see the problem? proc tabulate data=sashelp.class; format sex $sexfmt.; class age sex; table age, sex; run; If so, that is odd. (I'm not sure what would explain the difference we are seeing.) Perhaps we have other different options set. Or maybe a regional difference. Are you running EG in English? What locale is your Windows Regional Settings set to? Casey

CaseySmith · ‎10-30-2017

I typed the exact code you posted into a new program in EG 7.15 and I don't see the issue (red "format" statement). If you post some code that can be pasted into a new program in EG 7.15 to reproduce, I'll be happy to investigate. I agree with Tom, something in the prior code may be contributing. Casey

CaseySmith · ‎10-24-2017

Sorry, I'm pretty sure there is not currently a word wrap feature in the EG editor. As a consolation, starting in EG 7.13, you can more easily scroll horizontally via SHIFT + MouseWheel. Casey

CaseySmith · ‎10-23-2017

The SAS Enterprise Guide system requirements doc mentions the requirement: http://support.sas.com/documentation/installcenter/en/ikeguidesr/68009/PDF/default/sreq.pdf In the "Additional Requirement Information" section, it states: To run SAS Enterprise Guide after it is installed, you must have one of the following configurations: • SAS Foundation installed on the client machine (local configuration) • A metadata connection to a SAS Metadata Server and SAS Workspace Server with SAS/Integration Technologies (remote configuration) As others have mentioned, the EG standalone installer is simply a convenient way for installing EG (the client) only. This is most useful in a remote server environment, where you are only installing the EG client on end-user machines. If you need a local configuration (EG and local SAS Foundation), it is easier to deploy traditionally (with SAS Deployment Wizard) rather than the standalone installer.

CaseySmith · ‎10-18-2017

Happy to help. Glad you got it resolved!

CaseySmith · ‎10-16-2017

A couple things to check... Is Enterprise Guide 7.1 installed on the machine on which your Jenkins job is running? What user account is your Jenkins job running under? (add "whoami" command to your Jenkins job to confirm) Perhaps it is running as a different user than yourself (ex. service account)? Casey

CaseySmith · ‎10-13-2017

It appears the user's options file got into a bad format somehow. Yes, that problem note should resolve, or you can have them rename or delete just their options file: %appdata%\SAS\EnterpriseGuide\7.1\EGOptions.xml (ex. C:\Users\<userid>\AppData\Roaming\SAS\EnterpriseGuide\7.1\EGOptions.xml) Casey

CaseySmith · ‎10-10-2017

To set the EG config file option to get formatted values directly from the server: Close EG. Open the SEGuide.exe.config file from the EG installation directory (ex. C:\Program Files\SASHome\SASEnterpriseGuide\7.1\) into a text editor. There will be a commented out appSettings section that looks like this:   Change it to this:  <appSettings> <add key="FormatValuesAsNeeded" value="false" /> </appSettings> Re-start EG. To set transcodeaction=modify on your current server session: In EG, click File->New->Program. Copy/paste this into the program editor: options transcodeaction=modify; Click the Run button to run the program. At this point, re-open your data in the data grid and ensure it now appears as expected.

CaseySmith · ‎10-10-2017

Update: I just noticed you mentioned you are seeing those values with a column with $10. format (ProduktGenId:$10.). The issue I describe below is what we've seen for $HEX formatted values, so you might be seeing something else. Similar enough that I'd still try the workarounds below though. Yes, it is a known issue with binary/hex formatted data. It is related to the fact that SAS variables are stored as character or numeric -- there is no true binary type. You can workaround the issue by turning on the transcode=modify option on the server (ex. submit "options transcodeaction=modify;") AND instructing EG to get the formatted values from the server (rather than raw values, then explicitly formatting them) via this SEGuide.exe.config file option: <appSettings> <add key="FormatValuesAsNeeded" value="false" /> </appSettings> Casey ps- If interested in the details: The SAS server is returning the raw binary values to EG as a string of asterisks (ex. "******") -- since no native support for binary data. To get formatted values, EG explicitly formats the raw values retrieved from the server (for wide-data performance). So, EG explicitly formats the raw value "******..." using the format "$hex32.", resulting in "2A2A2A..." since "2A" is the hex value for the asterisk character. This problem can be worked around by submitting "options transcodeaction=modify;" on the server, which will cause the server to attempt to return the actual raw values. However, even with transcodeaction=modify, there is another potential problem. If the binary/hex value contains '00', the raw value that comes back from the server will be truncated, since that is normally a null terminator for a string. The workaround for this related issue is to instruct EG (via the config option above) to get the formatted values directly from the server, instead of formatting the raw values we get from the server.

CaseySmith · ‎09-28-2017

@Quentin, what I meant by that is providing options to enable users to more easily control the project log behavior. Currently, when the project log reaches a hard-coded maximum size (5 MB), EG notifies the user that the project log is full (and they get notified every time a new log is generated, which can be annoying). The only way to avoid the notification is to clear the project log. In a future release, we plan to give you a choice of behavior when the project log is on, such as: When the project log reaches: <specifySize> (MB) Dispay a warning message (but continue logging) Remove older items (a rolling log, truncated to size specified above, oldest items removed first) Export a time-stamped log, then clear the project log <specify name and location> Clear the project log when the project is closed Adding something to EG similar to the DM commands is interesting. Will think about that.

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