Changing Field Labels and Formats

KMoody

KMoody

Member
Progress: 10.2b SP7
OpenEdge Architect: 3.4.2.R342_v20090122-9I96EiWElHi8lheoJKJIvhM3JfVsYbRrgVIWL
OpenEdge OS: Windows 7 Professional 2009 SP1

If someone is connected to a database, I cannot use the Data Dictionary to change any field labels or formatting in that database; even if no user is referencing that field, I'm locked out and have to wait until all users disconnect from the database.

Why is this happening? Is there a workaround to this problem? Do I need to create my own Progress program that changes labels by referencing _File and _Field?
 
Have a data free version of the database that is essentially a schema. Apply changes to that database. Then create an incremental df to the production system during a time when nobody is connected.
You should not be changing the schema with users connected. Even if the CRC remains the same. And you should definitely not be faffing about and updating _file and _field records.
 
Thanks, Cringer. I'll try to do that.

This may seem obvious, but why can't we change the schema when users are connected? I understand why we shouldn't try deleting or radically changing tables, but changing a field label seems like a cosmetic change.

Is it always dangerous to change _File and _Field records? I need to programmatically set users' table permissions (Can-Read,Can-Write,Can-Create,Can-Delete), and the only way I can do that (to my knowledge) is to change the _File table.
 
Last edited:
That is because running procedures lock the schema in a way the data dictionary can't handle. Full stop. The data dictionary came along in the mid-1990s and has not been enhanced ever since ( of course new data types have been introduced, but nothing else ). Therefore the capabilities to change the schema online have not been introduced into the data dictionary.

Maybe Progess thinks that nobody is using it anymore after all the buzz around the Progress Developer Studio ( which includes a tool to maintain the schema ) so that it is not worth the effort. They buried it it - but you know - sometimes what's burried comes back and walks the earth ...

Heavy Regards, RealHeavyDude.
 
I've no experience with modifying Can-Read,Can-Write,Can-Create,Can-Delete, etc, so maybe that's ok to do, but I wouldn't be changing anything on a schema level myself with users connected.
 
In theory I guess I agree that changing labels is trivial and cosmetic and that you ought to be able to do so while the db is in use.

But I really have to wonder... why is this even a question? Are you coding on a production system?

As for the CAN-* fields... why are you changing those dynamically? CAN-* "security" is really only useful for a very small user base. And if that was the case I'm not following why you would need to dynamically change the values?
 
Thanks, everyone. I'll look into Progress Developer Studio.

TomBascom said:
As for the CAN-* fields... why are you changing those dynamically? CAN-* "security" is really only useful for a very small user base. And if that was the case I'm not following why you would need to dynamically change the values?
Click to expand...

It's a separate issue; I want to implement group-based table security. (Please see my thread titled "Using Groups with Procedure and Data Security. Unfortunately, I can't include the link. :() The only way I can do this (to my knowledge) is by manipulating Can-* permissions lists whenever a client is added or removed from a group. If there's a simpler or more secure way to do this, please let me know.
 
Last edited:
One approach might be to create your own table for users and then pervert the existing _user table & setuserid() functions to be "groups" or "roles".
 
Thanks, Cringer.

And Tom, that's a very good solution, especially since our existing code doesn't use _User or setuserid() at all. :D However, one downside would be any future OpenEdge features that use _User in unexpected ways.
 
Last edited:
The database provides two ways to authenticate against it so that there is a user identiy set:
  1. Username/password to authenticate against _User stored in the database
  2. Client Principal Object to authenticate against authentication system domains stored in the database
Using neither of them leaves you database wide open for anybody that can connect to it.

In our application, since we don't want to constantly maintain the _User table and the access privileges on _File and _Field we have chosen to:
  • Use the CPO to authenticate against the database. The CPO is the end result of a strong authentication done via third party tools.
  • There are only two technical accounts defined in _User, one used by all batch processes and AppServer agents running on the same machine, and one as a DBA account that can be used by the operator/DBA to interactively log into the database in emergency situations.
  • We set the permissions on _File so that a blank user id has no access privileges to any database table
That way we can ensure that no one is able to access anything in our database that is not authenticated properly. Application users are strong authenticated using the CPO. Batch processes / AppServer agents are running under a Unix account with no interactive login using the a password file to which only this Unix account has access privileges to authenticate with username / password.


Heavy Regards, RealHeavyDude.
 
Thanks! I think we might take a similar route - except we might not be able to get third party tools.

What does CPO stand for, by the way?
 
You must log in or register to reply here.
Back
Top