Btrieve field level security issues

[dgillz]

How do you keep a technical user from accessing certain fields within a Btrieve database? In my example we have a price override password stored in a file, and have application security so that only 2 people have access to maintain that part of the application (the application is Macola V7.5).

However, if you have access to Crystal Reports (as many users do) and you can connect to the database either thru ODBC or a native connection via file.ddf, the entire database is open to you. You can write a crystal report in 2 minutes that will tell you the price override password! There are lots of other areas I'd like to keep people out of as well.

In short, thios all or nothing access does not work well and I need to restrict people from reading the records at a field level. Software Support for Sage Mas90, Macola, Crystal Reports, Goldmine and MS Office

 

[ericmcl]

Hi dgillz,

You might want to look at setting the owner (ie a password) on the btrieve file itself. One of the things we did in the past (pre DDF days) was to set the owner name on the DAT file and supply the dictionary to the sites without the owner name. If they then tried to open the file outside our application (eg report writer etc) using the dicitonary, they would get an error 51 - Owner name is invalid.

Good luck.

Eric

 

[dgillz]

Eric,

The only problem is I need FIELD level not FILE level security. I do not believe you can do this with a field only, and the certain user(s) need access to the file itslef, but not to specific fields. Any ideas? Software Support for Sage Mas90, Macola, Crystal Reports, Goldmine and MS Office

 

[grnelson]

You could edit the DDF file and remove the fields you don't want available. As long as the main application does not require the DDF this would work for ODBC connection. However if the app requires the DDF files then you are probably out of luck.

Gil Gil

 

[Pervasivite]

If you lock the users out with an owner name (except for access through the application) and then set up users and groups via SQL security, you can then only allow users access to certain views of the data thus excluding the fields that you don't want them to see. If the data designed by the application designer is not set up with the idea of easy implementation of field level security, it may be a tedious job to do so, but it's certainly possible. You can also have two sets of DDFs and only allow certain users access to the complete set of DDFs, though I really don't know how the SRDE & MKDE would handle accessing the same set of data files via two sets of DDFs.

Regards,
Pervasivite

 

[dgillz]

GRnelson and Perv-

Please reread my post.

It is not a matter of restricting certain users "full access" to the DDFs. It is that the developers have restricted me, as a secondary developer, from full access to the DDFs. I need some way to reverse engineer the full DDFs so I can see everything in the table, not just what the DDFs which the developers, in their infinate wisdom, decided to give me access to. Software Support for Sage Mas90, Macola, Crystal Reports, Goldmine and MS Office

 

[dgillz]

Sorry folks, its been a long day. My last post was meant for another thread. Please ignore this post.
Software Support for Sage Mas90, Macola, Crystal Reports, Goldmine and MS Office

 

[Linda84]

The DDFs support field (column) level security. You can turn on security and set up users/groups and grant rights. You can grant rights on a table or column level.

Once granted, this security is enforced through all ODBC access based on the username/password used to login to the DDFs. It is not enforced through Btrieve access.

Once you turn on security, the DDF files are protected with an owner name that is the Master password. Attempts to access the database via Cryastal with the native Btrieve driver will require the user to enter the Master password in order to open the DDFs. So, unless you give out the Master password, you've essentially disabled access via the Native driver.

 

[dgillz]

Linda-

You have just re-stated my problem. I can turn security on, but it locks the user out of the Ddfs and then they cannot write ANY crystal reports with the native driver.

I want to allow access to the native ddfs at a table level but restrict certain fields.

Software Support for Sage Mas90, Macola, Crystal Reports, Goldmine and MS Office

 

[Linda84]

(Sorry, I have been out for awhile...)

You're right - once you turn on security you can't use the Native driver anymore unless you know the Master password. But, you can still use an ODBC connection and have the security enforced. So, essentially, you're locking them out of the free-for-all access methods, but still letting them have some types of access. Create an appropriate user/group with rights to the appropriate tables/columns, and then let them create reports via an ODBC connection while logged in as that user.