Try OpenEdge Now
skip to main content
Managing ABL Applications
Deployment Considerations : Deployment Topics and Tasks : Restricting database access

Restricting database access

OpenEdge provides the DBRSTRCT utility to restrict access to a database. If you restrict the database with DBRSTRCT, you cannot compile procedures or upgrade the database at the user site. You must provide a new empty database and a complete set of .r files to upgrade the application, and users must dump and reload their databases.
Because database access restrictions apply to you as well as to your users, you must make a copy of your original, unrestricted and unfrozen database, and store it under a separate name. That way, if you want to lessen the restrictions at a later time, you can dump the data in the restricted database and reload it into a copy of the original, unrestricted database.
You use the DBRSTRCT utility to define the kinds of database access all users, including yourself, are allowed. This is the syntax:
Syntax (UNIX)
dbrstrct database-name
In these commands, database-name is the name of the database you want to restrict. The utility starts OpenEdge and displays the following menu from which you can choose options that let you define privileges for the update and query activities:
To deny update or query access to all database files that are currently defined, choose 1. A second menu screen appears.
At the second menu, if you choose 1 (Deny updates), users can query but not update the database.
Any procedures you compile against a database before restricting that database are exempt from any restrictions you apply with the DBRSTRCT utility.
Make sure that you compile a complete set of dump procedures before you restrict the database. Otherwise, users will not be able to dump their database.
Note: Encrypted source procedures cannot be compiled against a restricted database.