1. OpenEdge Database security is implemented at the table level not the connection level. This means that, even with “blank user disabled”, a client may still connect. Security is only checked when that user attempts to access a table. Take careful note of the confirmation message:

   You are about to prevent the blank userid from
   accessing your database. Users who are not
   listed in the data security fields will not
   be able to compile procedures with this database.

   Notice it says nothing about connecting. Which brings us to point 2.

2. Table level access is compiled into a .r. Therefore an _user without any access to that table may still run the .r successfully (even the client connected without a user id).
3. The _user row may be modified or completely removed without affecting the running sessions (even after a STOP is raised).
4. The _user password can only be changed when connected via that _user.
5. The _user row , however, may be deleted by any session that has _can-delete on the _user table.
6. The same _user row may then be created again with a different password (yikes!). (Still does not affect any running sessions).

Please keep these behaviors in mind as you plan your security strategy.

PS: Please be aware that Progress says it will be modifying security including adding run-time capabilities sometime in the near future.