Create data view by location

[Hugonika]

In a library (consisting of one single directory) I need to create a data view. It should not depend on what name the user likes to give to the library. How can such a view be created?

For example, say we have a data set:

data "/tmp/dataset"; run;

Then it is straightforward to create an SQL view as follows:

proc sql;
  create view "/tmp/sqlview" as select * from "/tmp/dataset";
quit;

However I don't see how to create a data view in a similar way. The following code fails with the error "Expecting a name.":

data "/tmp/dataview" / view = "/tmp/dataview";
  set "/tmp/dataset";
run;

Is there a way to achieve what I need?

[Kurt_Bremser]

While it is possible to use physical names in certain statements for datasets, it is STRONGLY RECOMMENDED not to do this on a regular basis. Your SAS work should always be done through defined libraries.

As you can see, the VIEW= option of the DATA statement wants [LIBRARY.]VIEW and not a physical name.

[Hugonika]

I try to avoid it wherever possible. But here it is necessary.

I will use an SQL view if data views really don't work without a library.

[Kurt_Bremser]

It should NOT be necessary at all. You have a "system error" here.

A common path (and that is what you obviously have) needs to have a common library definition (in metadata or an autoexec file) so that all users use the same libname. This is how SAS is intended to work, and I STRONGLY recommend not to undermine that. Using logical names for a resource enables SAS administrators to seamlessly move data to a different physical location without forcing the users to adapt their code, among a lot of other things.

The use of physical path names was added as a kind of an afterthought, quite recently, and is not intended at all for production use with permanent data. As you can see, some code elements have not been adapted to support this, and there may even be a technical reason why this was not done. Keep in mind that data step views and SQL views are different beasts; SQL views are stored as pure text (really!), while data step views are pre-compiled and can't be used on another operating system, for instance.

Now, if certain users like to use a physical path for one of their individual libraries (which I still consider foolish), and they need a view there, then it's up to them to deal with that.

[Amir]

Hi @Hugonika, welcome to the SAS Communities forum and thanks for attempting some code and presenting your findings.

As the error message suggests, the syntax of the code needs some attention. I would suggest you compare what you need to do with some examples from the documentation and come back to us with any questions. Some clear examples are shown in the below link. You will note that none of the data set names are in quotes and perhaps that is why SAS was expecting a name.

https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/engsas7bdat/n1hoqlgqac8laan1eia6ogp9u3ke.htm

Thanks & kind regards,

Amir.

[Hugonika]

Thanks a lot, I have read the documentation. What I want to achieve is not documented there. But it is also not documented for SQL views. But what I want to achieve still works for them. So why not for data views?

[ballardw]

To have a chance at this you will have to hard code the entire path and point to an actual data set, i.e. a data set with the  sas7bdat extension. You would have to specify a library for the view, even if it isn't the one the "user" wants or assigns to that folder.  And the user would have to have that library available.

Views are very picky and have to be a SAS data set name i.e. libname.datasetname construct.

If you look closely at your system after running that

data "/tmp/dataset"; run;

you will find a newly created library that is likely to have a very meaningful name like WC000001. The letters and numbers may change but you will get something like than and the created data set would be referenced as WC000001.dataset. And then when you run that Proc sql you get a view in the same library with the code you show. Which will reference your Tmp folder most likely which is a very dangerous place to place anything you expect to persist.

Views are just instructions that tell SAS where to find referenced data. As such the path or library can't change or the instructions get rendered unusable.

What is the purpose of this? There may be a way that is less likely to be a problem.

[Hugonika]

The purpose is that I'm not the only user and that I can't tell others how they should name their libraries.

If there is really no solution, I will use an SQL view. However, I don't see a good reason why it shouldn't work with data views when it does with SQL views.

[Kurt_Bremser · Accepted solution]

When I create the data step view in a syntactically correct manner

data myfold.dataview / view=myfold.dataview;
set '/folders/myfolders/somewhere/dataset';
run;

and then use it

data check;
set myfold.dataview;
run;

I will also get one of those dynamically assigned libraries. Unless SAS finds a library which is already pointing to that path.

Bottom line: SAS always needs a library to access a dataset anyway, so you should accommodate that. It is the SAS way.

[Hugonika]

Thanks for your answer. But I have to make sure that if user A calls its library LIB_A and user B calls the its library LIB_B, both pointing to the same directory, the code still works.

As demonstrated, it is possible with SQL views *not* to refer to a library. Is it really not possible with data views? Where is this documented?

[FreelanceReinh]

---

@Hugonika wrote:

Thanks for your answer. But I have to make sure that if user A calls its library LIB_A and user B calls the its library LIB_B, both pointing to the same directory, the code still works.

---

Hello @Hugonika,

I think it should work as you describe, i.e., user A creates the DATA step view (say, named TEST) like this

libname lib_A '/tmp/';

data lib_A.test / view=lib_A.test;
/* code to define the view */
run;

and user B uses the view with an arbitrary libref pointing to the same physical location:

libname lib_B '/tmp/';

data want;
set lib_B.test;
/* more code */
run;

Edit: User A just needs to make sure that the "code to define the view" does not use librefs that are not defined (in the same way) in user B's environment. To avoid such librefs in the case of permanent datasets, this might even be one of the rare occasions where referring to physical paths of datasets is useful. (For PROC SQL views there is the USING clause available to embed a LIBNAME statement.)

[Hugonika]

Thanks a lot! That's it.

[Patrick]

@FreelanceReinh is always good for an approach others didn't think about. Kudos!

Below actually works.

options dlcreatedir;
libname source 'c:\temp\source';
data source.class;
  set sashelp.class;
run;
libname source clear;

libname lib_A 'c:\temp';
data lib_A.test / view=lib_A.test;
  set 'c:\temp\source\class.sas7bdat';
run;
libname lib_A clear;

libname lib_B 'c:\temp';
proc print data=lib_b.test;
run;
libname lib_B clear;

@Hugonika 

If defining views this way your users can even move them to other directories and they will still work. Just be very aware that you eventually created technical debt for yourself down the track as once these views get "distributed" changing the path to your source data will become very difficult.

You could also consider to define a pre-assigned library pointing to your source data and then use this libref for the source of your views.

...and in case you want to view to remain in a single location then your /tmp/dataset path could of course be a symbolic link pointing to your actual location.

And last but not least:

The only use case I've seen where using such hard-coded paths in view names made some sense to me was in a big environment where multiple developers/teams were working on BAU changes in parallel. So instead of always replicating the huge data volumes there was a script generating views pointing to the source data - and an init script used in all code which then assigned libraries accordingly (so full replication of the folder structures for code and data without the need to replicate data). ...but then: If one wanted to only change a single job in this large ETL process one had often to delete the target "view" - because else the code fell over during unit testing as SAS often can't replace a view with a table.

....so also here a may be better approach would have been for the %init macro to create concatenated libraries - just adding the Dev location for data to the actual location.

Not sure why you need these views and while not being able to enforce persistent libnames. Just take into consideration what the consequences of such an approach might be over time when things are "growing".

[Hugonika]

Thank you for the detailed explanation.