Desktop productivity for business analysts and programmers

Best practice for storing and sharing tables

Reply
Contributor
Posts: 40

Best practice for storing and sharing tables

What is the best way to let users share data in EG.

Scenario: Anthony and Benjamin, Carl, Daniel, Ethan

In EG Anthony uses som data on the server SASApp and creates at little query or two. By default this is stored as WORK.QUERY_FOR_CLASS_0001.

The next day Anthony, Benjamin, Carl, Daniel and Ethan wil use this data to do some more reporting, but Anthony is done for today.

Anthony then closes EG and it warns him "This project has references to temporary data......data will be deleted...".

Anthony has to sace the data because the source data changes over night and he can't recreate the dateset tomorrow.

Today we do the following:

Anthony uses "Task/Download datafiles to PC", and store i locally on the pc.

Anthony then sends it by email to Benjamin, C, D and E.

Benjamin uses "Task/Upload datafiles to PC". So do C, D and E.

As long as they work on the project they have to keep the files stored locally on the PC.

We use SAS 9.3 and EG 5.1.

Grand Advisor
Posts: 10,211

Re: Best practice for storing and sharing tables

Permanent libraries accessible to the users.

Contributor
Posts: 40

Re: Best practice for storing and sharing tables

Made a libname where the team has read and write access.

Anthony is able to store data in the library.

But the data don't show up in SAS Folders.

Anthony has to run the Update Metadata on the library, before it shows up.

Is this still part of best practice?

For the user it seems like unnecessarystep.

And to delete data, the user has to run task "Delete data set and formats" and then Update Metadata again.

In almost every other programs you can just right click and select "Delete" or somthing that easy.

Esteemed Advisor
Posts: 6,666

Re: Best practice for storing and sharing tables

If you have a metadata-assigned library, then the datasets in that library must also be handled by the metadata, and that is why the update metadata step is necessary.

If you have a simple libname lib 'path'; statement in one of the autoexec files, a right-click on the library in the server list and refresh is sufficient.

---------------------------------------------------------------------------------------------
Maxims of Maximally Efficient SAS Programmers
Respected Advisor
Posts: 3,063

Re: Best practice for storing and sharing tables

If you assign SAS libraries in metadata  with the AssignMode = 2 attribute in SMC then tables do not need to be registered in metadata to be visible in the EG server list. A refresh of the library will show any newly-created tables.

This technique is explained here:

http://support.sas.com/resources/papers/proceedings13/420-2013.pdf

Contributor
Posts: 40

Re: Best practice for storing and sharing tables

Thanks

The users find all there data through metadata/SAS Folders. I can teach them to go look at the serverlist and find data through libname, when they are looking for data created by other users, and not data from the dwh.

But it is inconsistant, to have data listed in two different areas. :smileyplain:

But I asked for best practice, and it is a better solution then what we are doing today.

So thanks for the help!

Community Manager
Posts: 2,696

Re: Best practice for storing and sharing tables

I agree with @ballardw -- If there is a continuous collaboration among users, then it's best to establish a SAS library on the server that all can access as needed.  You could create a folder/library that is specific to the project, and then grant file system rights only to the people who need to access it.

The Upload/Download tasks are a convenient workaround for one-off projects where it might be too much trouble to set up a shared space (if that involves IT), but it's not a great long-term approach.

Chris

Ask a Question
Discussion stats
  • 6 replies
  • 483 views
  • 7 likes
  • 5 in conversation