Library connection in E-guide without being pre-assigned

[tammy_dezilva]

Hi

I am just wondering how others set up their libraries in Management Console for users so that they can start up an Enterprise Guide session and run code without having to right click on a library and assign it first?  I know you can pre-assign libraries, but this then doesn't utilise metadata security for the tables.  Do you use the meta libname engine and assign your libraries that way in the autoexec?  While this solution would work, it doesn't seem like the best solution and I'm sure there is a better way of doing this.  I obviously don't want users to have to do libname statements in their code as it should be there ready to use.

thanks

Tammy

[PaulHomes · Accepted solution]

Hi Tammy,

The easiest way is to pre-assign them (in metadata or server autoexec). You can still pre-assign them using the Metadata Libname Engine (MLE) if you want to take advantage of metadata security. You'll want to be aware of all the intricacies regarding what you can and can't do with MLE libraries for the various metaout options. One of my favourite papers on this topic is What SAS Administrators Should Know about Libraries, Metadata, and SAS Enterprise Guide (SAS 9.2, SA.... It was written for SAS 9.2 but much of it is still relevant with SAS 9.4.

You could also get your users to use MLE in their libname statements (so the physical location is maintained in metadata) and possibly use EG autoexecs too.

If you need to protect the tables with metadata security even if the users bypass metadata and write their own libname statements you could also consider using SAS Metadata-Bound Libraries.

If you do pre-assign, just be aware that it may impact other apps too and if there are any database-backed libraries it may add additionally latency into any existing processes. There are a few different ways or handling this: defer=yes, dedicated custom app servers etc.

Cheers
Paul

[tammy_dezilva]

Awesome, thanks so much Paul. It sounds like MLEs might be the way to go after all. The defer=yes option sounds ideal for our SQL libraries too.

[SASKiwi]

Our preference is to pre-assign all libraries, both SAS data and non-SAS data using the native engine option. With external database libraries we use the DEFER=YES option so these are only connect when used. The reasons for doing this are:

• works for all SAS environments including EG, SAS Studio, VA, WRS, batch jobs etc.
• works efficiently and adds very little overhead when a job or session is started
• can still use metadata folder permissions to control whether they are executed (and visible in EG / SAS Studio) or not
• can use OS user / folder permissions to control access as well

I'm not saying this is best practice for everyone but just what works best for us. We did experiment with metadata engine libraries but found that performance wasn't so good in our environment. This was using SAS 9.3 - performance may well be better with 9.4.

[JuanS_OCS]

Good one @SASKiwi. I do the same on many of the environments I administer. Unfortunately, if for some reason, SAS Token Authentication is configured, you cannot set special permissions on the OS and, then, only the metadata can act as good protector of your environment, even if the performance is not as good as without the Metadata-bound libraries.

[SASKiwi]

Thanks @JuanS_OCS. I should have mentioned our environment is totally Windows and we find using AD groups allows us to align our OS directory permissions pretty closely to metadata ones. This allows us to avoid the complexities of metadata-bound libraries for now anyway. We use Windows authentication where possible or just passing through the Windows username / password. 

[tammy_dezilva]

Thanks SASKiwi. defer=yes definitely sounds like a great option which I'll test out today