Looking for quick& easy method to make table Read Only

[pk9]

I have two tables, Active.dbf and Inactive.dbf and want to simply make Inactive.dbf a read only table where users can not change but are able to view it. I am looking for hopefully a one line command. The two tables have the same structure. Are there any adverse affects.
Thanks kindly to all.
Peter

[Cheryl Lemire]

Peter,

I could be wrong, but I do not believe there is a way to make a 'table' read-only. It sounds like you want to move certain records to an inactive table and allow the viewing of those records only. The only way I know to control this is to make the 'forms/browses/reports/layouts' that the users have access to as read-only. That can easily be accomplished in the layout properties by restricting the access.

Not real sure why you would need two tables, active/inactive?

[Mario Prieto]

That should be done on the front -end

Is the viewing of the records done on a form, browse, or xdialog??
If it is done of a form or browse, you should just be able to go to the properties of each field on the form or browse and check the "Read-Only" property. Also you can do it on the form or browse properties by restricting changes.

hope this helps

[pk9]

Thanks Cheryl, Mario,
I am aware of placing restrictions on the front end but I was looking for simple option to make the table a view only. I need to maintain two databases for purposes of a paper trail.
Peter

[Stan Mathews]

Thanks Cheryl, Mario,
I am aware of placing restrictions on the front end but I was looking for simple option to make the table a view only. I need to maintain two databases for purposes of a paper trail.
Peter

How about a simple statement for the cansaverecord field rule event?

cancel()

[Tom Cone Jr]

Peter,

I don't think there's a single one-step answer. You might consider using field rules for the table to set the "skip" property "true" for each field. Then, no matter which form or browse is used to display records, the user won't be able to edit any of the records. This isn't complicated, but it can be tedious.

-- tom

[pk9]

Thanks, Stan/Tom
I was trying to avoid field by field restrictions. What would happen if the dbf file was made read only by the OS?
Peter

[Cheryl Lemire]

Peter,

I need to maintain two databases for purposes of a paper trail.

How are you creating the second db and keeping it updated? You mention a paper trail? If the two db's are exactly the same, then wouldn't just one suffice as your paper trail?

It almost sounds to me more like you need an audit trail, not a second db? Can you explain in more detail exactly what you are trying to accomplish?

[Stan Mathews]

Thanks, Stan/Tom
I was trying to avoid field by field restrictions. What would happen if the dbf file was made read only by the OS?
Peter

How about a simple statement for the cansaverecord field rule event?

cancel()

This is not a field by field solution. This is a record level event not tied to any field.

[Tom Cone Jr]

Peter, the file.attributes_set() method seems able to set the "read only" attribute for a file. why not try it with a table and let us know ?

-- tom

[pk9]

Cheryl,
The structure is the same not the data. As the dbf names indicate some data from the Active will be moved over to the Inactive and the Inactive dbf rarely used. There is a 3rd and 4th dbf called Archived and Issued respectively that have the same functionallity as Inactive. As you can imagine over time (multi years) the Inactive and Archived etc will be very large db that do not need to be used with the Active.dbf
Hope that helps explain dbf design.
Peter

PS Tom I will try your function and post results.
Thanks

[masteralone]

Peter,

I am contemplating the same type of structure so that the working table remains small and fast while the inactive and archive slowly grow as data is moved from the active in a timely process.

Thinking on it, if you make the db (table) read only, you won't be able to migrate data from active to inactive. In reading thru these posts, I think it would be better if you were to create a form to view the data in inactive that doesn't allow enter or change modes.

[Peter.Wayne]

Stan has twice posted a solution that works and is better than changing the file properties in Windows. Any user can change the file properties from read-only to read-write from the OS level, if they know how to use the "attrib" command from a command prompt.
Rather than code for the CanSaveRecord event, though, I have usually coded for the CanChangeRecord event. A simple script in the field rules for CanChangeRecord:

cancel()
ui_msg_box("Read-only data","You are not authorized to make changes here!")

It's the only place you have to put the code and applies to all forms and browses you create; it doesn't have to be repeated anywhere. You should be aware that you can still write Xbasic scripts that will move records to the archive table, as Xbasic scripts will override the field rules. I don't know for sure (since I haven't tried it) but I would think that operations will also override the field rules, since operations get translated into Xbasic commands.

If you put the read-only restriction in the field rules, you have the option of overriding it for, say, a user classified as an "administrator". However, if you're looking for a codeless way to make the table read-only for users, why not use the security features built in to A5? You can set the user permissions for the table to "deny" for changes, deletions, additions, for the group "sales", yet all persons in the group "administrator" to change the records.

[jmatienza]

What about protecting the tables from the admin?

I've been wondering how legally sensitive information, such as medical records, can be protected from editing once they've been created. The posts here seem to be saying that access and edits can be prevented only on the form/browse level. Meaning there is no way to prevent someone with admin rights from altering existing data in tables?

[Peter.Wayne]

Jim,
No, you don't have to change each form or browse. One simple way is to have a logical field called, say, "signed", and have the code for the CanChangeRecord event:

if signed=.t. then
  cancel()
  ui_msg_box("Signed Note","Changes not allowed!")
end if

If corrections have to be made, you can have another form or Xdialog that will add an addendum to the pre-existing note, clearly marked as an addendum, with the date and time and the name of the user making the addendum.

The beauty of this scheme is that once the user has indicated "signed" is .T., they can't change "signed" back to .F. to make an unauthorized change.

Unfortunately, nothing prevents a user with access to the control panel and to the field rules from opening the control panel and changing the field rules temporarily. So you have to make sure the control panel is hidden and that the table is encrypted, so that a user cannot buy a copy of Alpha Five, open the table and make changes.