There are good discussions here about the pros/cons of "locking" an EG project -- it's always a good idea to define exactly what behaviors you're trying to encourage or prevent, and then look to see what technology toggles, if any, can help to achieve that. From an EG project file perspective, you have these options: Encrypt the project file with a password. (File->Project Properties->Security) This will require that anyone who opens the project supply a password before being allowed to open it. There is no "read/write" password concept -- either you can open it or you can't. It's no secret that the EG project file is a ZIP file format; this password is on the ZIP archive. Use this option with caution, as SAS Tech Support can't help you to recover a lost password. Make the project file READ ONLY. Use the operating system features to mark the file as Read-only, and then users cannot save/overwrite the file in place. This prevents unintentional modification of a project file while still allowing a user to run the project and see results. It does not prevent a Save As operation, where a user makes a local copy of the file in a writable location. Use roles/capabilities in SAS Metadata to prevent users from modifying/running/saving projects within EG. This feature allows a SAS administrator to designate who can use certain EG features, including modifying/saving certain properties of the EG project file. These role-based behaviors would apply to a user across all project files he/she accessed, not just a select subset. You can probably imagine using a combination of these techniques to control access. In my opinion, locking down the EG capabilities in this way would offer only limited effect. If you truly want a read-only, opaque process that an end-user can trigger without exposing too much IP, it's better to consider a stored process on a central server. Chris
... View more
