About CaseySmith

CaseySmith · ‎08-07-2015

I found the entry in our internal tracking system related to this issue, but I did not find an associated SAS Note, and I doubt it is covered in any paper. I confirmed it was a bug in 4.3 and has been fixed. A little more detail: The cause of the bug is the fact that EG 4.3 attempted to auto-wrap code lines when exporting, so that the line lengths would not be too long (thus more likely to run on other servers with potentially different line length limits). EG 5.1 and later do not attempt to auto-wrap code lines when exporting, both since we weren't able to do it reliably in all scenarios and since the more reasonable expectation is that exported code will be *exactly* the same (line lengths and all) as what was in the editor.

CaseySmith · ‎08-07-2015

Also, make sure you have access permissions to the Recovery.xml file that is stored in that location (the location specified in your Tools->Options->Project Recovery->Save location). For example, confirm that you can open it in a text editor. Though I agree with Chris, it looks more like a possible network file storage issue.

CaseySmith · ‎08-06-2015

As ballardw alluded to... unfortunately no, there is not currently a way to disconnect EG from a server session and reconnect to the same session later (preserving temporary data, etc.). Once the connection is severed, that server session cannot be re-established with EG. We are researching and hoping to add this capability (disconnect/reconnect) in a future release, but for now ballardw's suggestion (using permanent libraries) is recommended if you frequently switch between networks.

CaseySmith · ‎08-06-2015

This is a bug in EG 4.3 that was fixed in EG 5.1 (and later). I am easily able to reproduce this issue in EG 4.3 (by pasting the "For example" code in the original post into a code node, then selecting Export->Export Program... to export). I also confirmed the issue does not occur in 5.1, 6.1, 7.1, or 7.11.

CaseySmith · ‎07-28-2015

Hi Johann, Yes, EG 7.1 and 7.11 are supported with .NET Framework 4.5.2. Casey

CaseySmith · ‎07-22-2015

If you have SAS/ACCESS to PC Files licensed, I think you'll have better performance using it to export larger data sources to Microsoft Access, rather than the EG export. For example: /* MS Access database already exists */ LIBNAME mylib ACCESS 'C:\temp\Demo.accdb'; /* write new table to the database */ data mylib.myclass; set sashelp.class; run; See SAS/ACCESS(R) 9.4 Interface to PC Files: Reference, Third Edition Casey

CaseySmith · ‎07-21-2015

When you submit "libname test oledb;" in SAS BASE editor (an interactive SAS session), it will prompt you for the missing connection information (by displaying the Data Link Properties dialog, where you must specify the OLEDB provider and connection settings). EG submits code to a non-interactive SAS workspace session, very similar to batch execution, thus interactive features of the server (such as this and other prompts) are not available in EG. Therefore, you need to provide the full connection information in the libname statement when submitting from EG. Here is an example using the Microsoft OLE DB Provider for SQL Server (sqloledb) to connect to a SQL server database: libname test oledb provider=sqloledb properties=("user id"=cassmi password=pw "data source"='striper' "initial catalog"=egtest); Casey

CaseySmith · ‎07-21-2015

Hi Rafael, In EG 7.1, a context menu item (when you right-click a range of cells) called "Copy with headers" was added to the data grid, which will allow you to copy/paste the column headers in addition to the values. Casey

CaseySmith · ‎07-17-2015

CherylMac wrote: Could you clarify one thing for me? SAS is set up to run on our local machine and not a SAS server so we do not have user profiles. Is this why the History window shows all authors as PUBLIC? Hi Cheryl, This was a bug that was fixed in EG 7.11. When you are running against a local SAS server (without a connection profile), we now (in 7.11) show the logged in Windows user as the author in the program history. Casey

CaseySmith · ‎07-14-2015

Shen, you are welcome. Yes, you are correct... that changed in 7.11 as part of those changes as well. The CurrentUICulture in 7.11 matches the language folders in the EG installation directory exactly, thus neutral cultures (except for the three Chinese languages, differentiated by specific cultures), whereas EG 7.1 assumed the default region, thus always used a specific culture. Glad you figured it out!

CaseySmith · ‎07-14-2015

Prior to 7.11, the thread culture (CurrentCulture) and thread UI culture (CurrentUICulture) were always the same and matched the EG display language. Starting in 7.11, they can be set independently (some users prefer EG to display in one language, but for culture-specific values to be formatted in another). The thread culture is determined by your Windows Regional Settings and affects the default format for dates, times, numbers, currency values, the sorting order of text, casing conventions, and string comparisons. The thread UI culture is determined by your EG display language (set in Tools->Options->General) and controls which culture-specific resources are loaded at run-time. If your EG display language is set to Japanese, then your thread's CurrentUICulture will be set to "ja", which should load "ja" resources for your custom task if present. Also, make sure you are using CurrentUICulture (rather than CurrentCulture) when you need to get the display culture/language. Use CurrentCulture for formatting of dates, times, etc.

CaseySmith · ‎07-07-2015

Hi BobTheSASUser, yes, the easiest way to workaround is to copy and paste the Export Task to the original (correct) Process Flow and then delete it from the (incorrect) Process Flow it was in. After that, it will stay in the correct process flow and can be re-run as expected. (You can access copy and paste menu items on the context menu by right-clicking the Export Task node.)

CaseySmith · ‎06-26-2015

Hi, I think your best bet is to parse the object spawner logs, which will show you the connections to SAS workspace servers from EG (APPNAME=SAS Enterprise Guide), the user, and the process ID of the sas.exe process. For example: 2015-06-26T13:49:22,799 INFO [00006715] :cassmi@CARYNT - New client connection (204) accepted from server port 8591 for user cassmi@CARYNT. Encryption level is Credentials using encryption algorithm SASProprietary. Peer IP address and port are [::ffff:10.40.13.23]:11997 for APPNAME=SAS Enterprise Guide. 2015-06-26T13:49:23,142 INFO [00006715] :cassmi@CARYNT - Created process 19952 using credentials cassmi@CARYNT (child id 93). 2015-06-26T13:49:23,158 INFO [00006961] :SYSTEM@UITSRV04 - New out call client connection (205) for launched server (child 93). Peer IP address and port are [::ffff:10.121.18.73]:57832. 2015-06-26T13:49:23,158 INFO [00006966] :SYSTEM@UITSRV04 - Launched process 19952 (child id 93) is now running as process 17908. 2015-06-26T13:49:23,158 INFO [00006961] :SYSTEM@UITSRV04 - Client connection 204 for user cassmi@CARYNT closed. 2015-06-26T14:01:34,302 INFO [00006975] :SYSTEM@UITSRV04 - Client connection 205 for user cassmi@CARYNT closed. 2015-06-26T14:01:34,333 INFO [00006722] :SYSTEM@UITSRV04 - Process 17908 (originally 19952) for user cassmi@CARYNT (child id 93) has ended. Casey

CaseySmith · ‎06-26-2015

Hi, I think your best bet is to parse the object spawner logs, which will show you the connections to SAS workspace servers from EG (APPNAME=SAS Enterprise Guide), the user, and the process ID of the sas.exe process. For example: 2015-06-26T13:49:22,799 INFO [00006715] :cassmi@CARYNT - New client connection (204) accepted from server port 8591 for user cassmi@CARYNT. Encryption level is Credentials using encryption algorithm SASProprietary. Peer IP address and port are [::ffff:10.40.13.23]:11997 for APPNAME=SAS Enterprise Guide. 2015-06-26T13:49:23,142 INFO [00006715] :cassmi@CARYNT - Created process 19952 using credentials cassmi@CARYNT (child id 93). 2015-06-26T13:49:23,158 INFO [00006961] :SYSTEM@UITSRV04 - New out call client connection (205) for launched server (child 93). Peer IP address and port are [::ffff:10.121.18.73]:57832. 2015-06-26T13:49:23,158 INFO [00006966] :SYSTEM@UITSRV04 - Launched process 19952 (child id 93) is now running as process 17908. 2015-06-26T13:49:23,158 INFO [00006961] :SYSTEM@UITSRV04 - Client connection 204 for user cassmi@CARYNT closed. 2015-06-26T14:01:34,302 INFO [00006975] :SYSTEM@UITSRV04 - Client connection 205 for user cassmi@CARYNT closed. 2015-06-26T14:01:34,333 INFO [00006722] :SYSTEM@UITSRV04 - Process 17908 (originally 19952) for user cassmi@CARYNT (child id 93) has ended. Casey

CaseySmith · ‎06-26-2015

Hi, this is a bug that was unfortunately re-introduced in EG 7.1. It is fixed in EG 7.11. See 42716 - Export task might not display in the correct Process Flow in SAS® Enterprise Guide®.

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