Program block result dataset pointing to wrong library

[JoonaH]

I have defined a so to speak redefinable WORK library named W. The idea is that W is the default library for all datasets and I can change where the datasets are actually created. For example normally it's pointing to WORK but in some cases I want the datasets from the same program to persist and then I define W to point to SASUSER.

Let's say I'm creating a dataset named W.SOMEDATA. Now everything works fine when I make query block or import block. The resulting dataset in the EG process flow is shown to originate from library W no matter where W is actually pointing. But when I make a program block then EG decides that it wants to find the library where W is pointing to. And so if I had W point at WORK then the resulting dataset originates from WORK.SOMEDATA. Now when I change W to point at SASUSER and run the program the result will be SASUSER.SOMEDATA, which causes the process flow links to break.

So what I'm searching for is a way to create the dataset with program block so that it is shown to originate from library W in the process flow while W is pointing to some already existing library.

[PhilC]

Me too.

I would like to add a file link to a text file I've exported (PROC EXPORT) so that it displays in the EG project's process flow.  (like if I had used the EG export "task", anyway)  I believe we're looking for similar things.

[PhilC]

I think I see why you use this libname label, i.e. "w",  I take it that using macros such as "&w" is out of the question.  Continuing to threaten destruction of the system that you have already created for your purposes, what about employing the option: ?

OPTIONS USER=library;

[JoonaH]

W is just an example name. The main point is to have a library that is usually same as WORK, but which I can change to some permanent library like SASUSER if needed. And I'm kinda of just started this "transition" to this new system so anything can be still changed if a better solution is found 🙂

OPTIONS USER=library; doesn't unfortunately help in this case. It is the same as using W except instead of writing W. in front of your table names you instead write nothing. The final result remains the same: defining USER=WORK results datasets in the process flow to point at WORK, not USER or "nothing", and then changing USER=SASUSER results datasets in the process flow to point at SASUSER, which breaks the link chain, since your program was assuming the source data of each program block to be from WORK.

Another downside is that EG built-in blocks like query builder do not support "nothing" as library reference. You will have to specifically name the library where you want to put the dataset in. Though you can of course tell it to go to USER-library.

[JoonaH]

Similiar, but I think these things are fundamentally rather different since I'm creating datasets with PROC SQL while you are creating files with PROC EXPORT. This this you mentioned haven't given me problems, but now that you mention it I have encountered the same thing. Of course you can manually add the file and do the link if you always create the file with the same name, but if you create files with different names then this can be a problem.

[JoonaH]

After discussing with support I got a solution that by defining W with the following statement should work with the newest SAS server version. I will have to wait for our company to update to that to test this. If someone has that and cares to try then go ahead.

%let work_path=%sysfunc(pathname(WORK));
libname W "&work_path";

Meanwhile I have been able to user workaround by not defining W to be exatcly the same as the target library like SASUSER or WORK. In SAS user case I define W to be subfolder WORK in SASUSER. In WORK this couldn't be done as I have no rights to create folder inside the sessios specific WORK folder However I realized that the WORK folder is always a two level structure. So if C:\SASWORKS is the main folder where all WORK folder are generated then WORK physically points to C:\SASWORKS\Temp-session\WORK. Now I can define W to point at C:\SASWORKS\Temp-session, which still works like C:\SASWORKS\Temp-session\WORK in the sense that it gets erased after session is closed.

[PhilC]

Goodluck,

As a user of SAS in a company that can't always upgrade to the newest version immediately, I commiserate with you.  

Looks like your learning SAS.  Temp and permanent libraries are an important issue, and I've know I've developed out-of-the-box methods of dealing with that too.  

If you're wanting to have a libname for a project that "sticks" with the project.  You can create a libname in the same directory/folder of your EG project (local computer).  EG provides the macro variable "_CLIENTPROJECTPATH".  If one can extract the folder URL from that then one can use that to define and create libnames, one that saves the datasets to the folder close to where the project is saved.  Just in case this helps, I use this code to get that folder URL:

data _NULL_; 
  _CLIENTPROJECTPATH="&_CLIENTPROJECTPATH"; 
  put _CLIENTPROJECTPATH= ;
  re = prxparse("/['""]*(.*)[\\\/][^\\\/]*['""]*$/");
  if PRXMATCH(re,_CLIENTPROJECTPATH) then do; 
    call PRXPOSN(re,1,position, length);
    egp_DIR=substr(_CLIENTPROJECTPATH,position,length);
    put egp_DIR=;
    call symput ("egp_DIR",strip(egp_DIR));

      * The macro variable should be egp_DIR is the project's parent directory/folder;
  end; 
run; 

/*  Breakdown of regular expression:*/
/****************************************/
/*    /        the beginning and end of the regular expression */
/*    ['""]*   Matches either single or double quotes and any number of those characters */
/*    [\\\/]   Finds one character that is either a slash \/ or back slash \\ */
/*             this will be the slash charachter separating the file name and the folder path in this context.*/
/*    [^\\\/]* Finds many characters that are not a character that is either a slash or back slash*/
/*             in this context, this is suppoese to match the file name*/
/*    .*       This matches characters between the beginning of the string until the single slash character*/
/*             in this context, this is the path name*/
/*    (.*)     The parenthese surrounding this expression identifies the matching string as a string of */
/*             interest for the PRXMATCH and PRXPOSN functions.*/

[JoonaH]

Thanks. I have been thinking of similiar solutions but instead so that I would create a subfolder inside SASUSER so that the datasets would remain on the SAS-server and they would not need to travel between networks.

[JoonaH]

There was a miscommunication between me and support. This feature will not work any differently on newest SAS versions, so these workarounds are still valid.