Submit this code from EG to check your server session encoding and locale, to make sure they are set as expected:   proc options group=languagecontrol; run;   If not, you may be encountering the fact that EG sets the server session locale (which can also alter the server session encoding) by default to match the EG Display language.   In Enterprise Guide, see Tools->Options->General->Enterprise Guide language settings->Server session locale.  It defaults to "Use the Enterprise Guide display language".  In which case, when EG connects to a workspace server, it sets the locale on the server session to match EG's display language.  For example, if EG's Display langauge is English, the server session locale will be set to "EN_US".   Setting the locale on the server session will also change the encoding if not explicitly set on the server.  So, since the server session locale was set to "EN_US" by EG, the server session encoding might also result in WLATIN1.   If you want to preserve the default server session locale and encoding (as configured on the server), change EG's Tools->Options->General->Enterprise Guide language settings->Server session locale option to "Use the locale of the server". ... View more

Is the record count accurate or missing value in the sashelp.vtable dictionary table for your SPD data?   For example, submit the following (replacing with your SPD libname and a memname in that library):   proc sql; select * from sashelp.vtable where libname eq "SASHELP" and memname eq "CLASS"; quit;   Does the "Number of Physical Observations" (nobs) and "Number of Logical Observations" (nlobs) correctly report the record count for your data?  Or is it missing value?  (I'm curious whether the record count is surfaced through the SPD engine.)   If the dictionary table does return the record count for your data, the issue may be in EG for not exposing it.   As Tom indicated, SAS can't cheaply determine the record count for DBMS (it would have to make a pass through the data, which is expensive, thus avoids).  The record count in the sashelp.vtable dictionary is a missing value in this case.  Same goes for SAS views, since the data for views is dynamically retrieved.    Casey ... View more

The EG automation interface (ex. VBScript) does support Save and SaveAs for EG projects, but as you noted, this would not solve your problem if you wish to SaveAs the project (aka. template) the user currently has open.  I can't think of an easy solution other than making your template EG project file read-only and instructing users to manually SaveAs.  There isn't a built-in way to Save/SaveAs a project by running something in said project.   If you really want an automated solution and willing to get dirty, I bet you could accomplish with a "Save Current Project As" custom task that you could add as a final step in your process flow.  However, you'd have to hook into EG's non-public APIs to perform the SaveAs on the project (without prompting).  And you'd have to deploy the custom task to your users' EG installations (whoever was going to use the template project, containing a reference to the custom task).  While possible, I suspect this would be more trouble than just instructing users to manually SaveAs.   Casey ... View more

Mark,   I'm glad Chris' solution will work for you.  I agree, that sounds like the best route to take.  However, I wanted to provide a little more information for clarity...   The "EGPrjObj.CodeCollection.Add" call in your example adds a new program to the EG project (equivalent to interactive File->New->Program).  The key here is that this new program is embedded (stored in the EG project (.egp file)) by default, rather than a shortcut to a .sas file on disk.  This is important because the _SASPROGRAMFILE macro value is empty (two single quotes) for embedded programs, since there is no physical program file to reference.  For example, you'll see this near the top of the log:   %LET _SASPROGRAMFILE='';   So, EG is generating the code that sets the _SASPROGRAMFILE macro in this case (both interactively and via automation), it just happens to be set to empty, since it is an embedded program (there is no program file).   If you add an existing .sas file to an EG project (ex. File->Open->Program, interactively), the _SASPROGRAMFILE macro will contain the path to the .sas file (when run interactively or via automation).  The root problem is there does not appear to be a way to add an existing .sas program (reference/shortcut) to an EG project via automation.  I did not find an API in the current automation interface for doing this.   Hope that helps.   Casey ... View more

Hi @Ditza,   The Log Summary currently only summarizes errors, warnings, and notes.  (It does not support custom categories.)  However, you can generate your own errors, warnings, or notes with code such as:   %put NOTE: MERGE statement has more than one data set with repeats of BY values; %put WARNING: MERGE statement has more than one data set with repeats of BY values; %put ERROR: MERGE statement has more than one data set with repeats of BY values;   Resulting in:   Casey ... View more

The EG editor's syntax suggestion/autocompletion feature could be the cause of this slowdown -- especially in older EG releases and with larger programs.  You could try turning it off (uncheck Enable Autocomplete in Program menu->Editor Options->Autocomplete tab).  If that is the cause, you should see a marked improvement.  (This particular issue has been largely addressed in newer EG releases.)   (Though I just noticed @jakub_deka had already tried disabling Autocompletion.  It is still the first thing I would try for slow keystrokes, since it has been the culprit for at least a couple cases.)   Casey ... View more

Ok, from the screenshot I can tell what is going on...  it is as I alluded to in earlier post...   The values in your column contain your default delimiter, which is the semi-colon given your locale settings.  When you export as "Text Files (*.txt)", the values are separated by your default list separator (aka. delimiter).  Any values that contain your delimiter character are wrapped in quotes (so they aren't ambiguous with the delimiters).   So, if you do not want your values quoted, export to a text format that uses delimiters which are not contained in your values.  For example, in this case (where your values contain semi-colons and semi-colon is the default list separator in your locale) export to space-delimited or tab-delimited text file instead.   Casey ... View more

What version of EG (listed in Help->About) are you using?  In newer versions of EG, only values that contain the delimiter will be wrapped in quotes when exported to text (to avoid the ambiguity). ... View more