Generally, you do not CREATE library references through the SAS Add-In for Microsoft Office, you USE library references that have already been set up in the Metadata for the SAS Enterprise Intelligence Platform.
This allows your SAS Administrator to set security for the data resources in one central location. Your SAS Administrator will use the SAS Management Console to define libraries and tables that are available for end-users to access from client applications like Excel or Word or SAS Web Report Studio or SAS Enterprise Guide.
If you are trying to open a data source using the SAS Add-In for Microsoft Office in Excel and you do not see the expected libraries or tables on the server that you pick, then you need to discuss your need to access those tables with your SAS Administrator or Data Manager.
Otherwise, if you need help setting up library references or security on the SAS Enterprise Intelligence Platform, you might consider contacing SAS Technical Support for help.
In EG, I could pick the dataset either from libraries or files for analysis. However, SAS Add-in for EXCEL only allows picking source from libraries only. Is there anyway to use SAS dataset without accessing SAS libraries?
Doing that (use a SAS dataset without accessing a SAS library defined in the metadata) would bypass all the security set up in the metadata. This is generally not a good idea. I believe that if you have local datasets (on your C drive, for example) that you can open them as a data source by navigating to the local drive location for the file.
I strongly suggest, however, that you talk to your SAS Administrator about how you can access the libraries and tables without bypassing the metadata security.
> Hi, Ted:
> Doing that (use a SAS dataset without accessing a
> SAS library defined in the metadata) would bypass
> all the security set up in the metadata. This is
> generally not a good idea. I believe that if you
> have local datasets (on your C drive, for example)
> that you can open them as a data source by
> navigating to the local drive location for the file.
> I strongly suggest, however, that you talk to your
> SAS Administrator about how you can access the
> libraries and tables without bypassing the metadata
Interesting comment.. if you are going to protect the securtity of files through SAS Metadata you are asking for trouble. All our security is at the drive level and as stated you can get to your file system via the Enterprise Guide option for files. I think it is critical that you have file level security and that the Excel Add-in should have the same functionality as Enterprise Guide in terms of accessing files that are stored on the file drive... I highly recommend that you do not depend on Metadata security, but rather make sure you have setup file security as it is critical for proper industry standard protection no matter what the platform.
If you read the Platform Administration Security documentation or take the Platform Admin classes, we discuss using both drive level security and metadata security. The Metadata security adds row and column level security to the tables, on top of or in conjunction with drive level security. In addition, with the ability to create Information Maps, you can "hide" necessary joins or filtering from less experienced users.
In classes, I see different users for EG versus the SAS Add-in for Microsoft Office. Generally, the EG users are more comfortable with programming concepts and accessing data and even with seeing/writing code; while the Microsoft Office/Add-In students -mostly- want to point and click their way to reports and analysis without knowing the behind-the-scenes accessing of data that is going on.
Based on that experience, I can understand why the Add-In for Microsoft Office has different ways to access data than EG. And when you look at EG or the Add-In in comparison to Web Report Studio, the "leveled" approach to data access becomes even more apparent. In Web Report Studio, users can only point to data sources which have an Information Map defined for them. So, Web Report Studio is MORE restrictive than either EG and the SAS Add-In for Microsoft Office. Again, this is because of the different user base. EG users can modify code and build SAS Stored Processes...Add-In users can run tasks and run stored processes, but I think the underlying assumption is that programmers/developers will use EG and not the Add-In for development.
I understand that EG and SAS Add-in for EXCEL are meant to be for different users. However, nowadays some roles you could not draw a clear line between programmer and analyst for them. As an analyst with programming skills, I would use whatever tools are available to me and delivery results as soon as possible.
I would rather let the users and platform administer decide what is best for them instead of limiting users capacility by some assumptions.