Metadata Bound Libraries are not something I had looked into before, but after some light reading/testing, they do seem to be the best bet for accomplishing what I need.  Never a fan of additional administrative overhead, but they provide the fine-level control I can't seem to get from the standard metadata authorizations or file system.  And the ability to control permissions for manually issued libname statements is an added bonus.   Thanks for the insight. ... View more

This is a BASE Library with explicitly registered tables (no pre-assignment).  The users are accessing it via Enterprise Guide, typically via Query Builders but also with a code node written for them.  The intent is that they be able to insert records into, update existing records, and delete records from these tables.  However, I do not want them to do anything to the table structures themselves, since I created the tables with indexes and check constraints.   As an example, I have a table named "INDICATORS" (structure not important for this exercise).  The authorizations on the metadata folder containing the library and tables allow RM,R,W for the user and deny all other rights.  When trying to run the query below, the resulting error is "ERROR: The Delete permission is required to delete data from table/view QOAUFL.INDICATORS.DATA.".     PROC SQL; DELETE FROM QOAUFL.INDICATORS; QUIT;   Accordingly I add the "Delete" authorization to the metadata folder and the above statement runs as desired.  However, if I run the next statement, the table is deleted, which I do not want to be permitted.     PROC SQL; DROP TABLE QOAUFL.INDICATORS; QUIT; I'm unsure of how to set the authorizations to allow deletion of data within a table without allowing the deletion of the table itself. ... View more

You are absolutely correct about the user's ability to override the readonly flag.  We are relying upon the fact that most of our users don't know about libname statements and, even if they did, they don't know what the file system structure looks like.  Consequently, they can't construct the proper libname statement.   A gotcha with this situation is that we can't enforce the permissions at the file system or authorization level because we actually need the users to be able to alter the library contents in specific cases.  In those instances we obfuscate the functionality in compiled macros, internally using the reverse of your suggestion:  issue a libname statement granting write access, executing the appropriating updates, and issuing a second libname statement flipping back to readonly. ... View more

In our environment the users rely almost exclusively on the metadata information presented in Enterprise Guide; most of them have never seen a LIBNAME statement before.  Since we need the libraries to be protected from the moment the user connects from EG, we have to secure them in the metadata definitions.  Of course, I am always open to alternate ways to control access that can be handled programatically. ... View more

Thank you all for the great input.  It sounds like we should be able to move forward with VS 2017 as long as we set the correct framework target (that chart is really helpful).  I'll try copying the template files to the 2017 directory and hope that Microsoft hasn't changed the format since 2013; it wouldn't be the first time they've done that to me. ... View more