Is it possible to lock portions of a table?

[RTaylor1853]

I have a form that stats are put into. I was wondering if it was possible to lock portions of that table attached to the form to prevent changes to previous months stats but still be able to view them and still be able to add/edit "this months" stats? I've almost debated on just separating the stats info into different tables if that would be easier. Any thoughts?

[ADezii]

I have a form that stats are put into. I was wondering if it was possible to lock portions of that table attached to the form to prevent changes to previous months stats but still be able to view them and still be able to add/edit "this months" stats? I've almost debated on just separating the stats info into different tables if that would be easier. Any thoughts?

Couldn't you simply Lock the Control on the Form that displays the Previous Month's Stats?

[RTaylor1853]

If that's done though, would you still be able to add stats for the current month? All stats are in the same table, use the same form.

[NeoPa]

Your code could determine which is currently in there and set the status depending on whether it's historical or recent. Bear in mind this won't work for multiple-record type forms (See Why Values in Unbound Form Controls do not Persist).

[RTaylor1853]

Your code could determine which is currently in there and set the status depending on whether it's historical or recent. Bear in mind this won't work for multiple-record type forms (See Why Values in Unbound Form Controls do not Persist).

Well then, that's out of the quetsion.

[NeoPa]

OK. I'll play.

Does that mean you're using a continuous form?

It's generally easier if you just say what you need to though ;)

[jimatqsi]

I would handle it like this, whether your form is continuous or single record: I would add an OnEnter event handler for every text box in the detail. In each OnEnter routine I would simply have Call LockOut. The LockOut routine would say:

' prevent data changes unles the transaction is this month
If month(me!transactiondate)=month(Date()) then
 me!txtField1.locked = false
 me!txtField2.locked = false
 ....
else
  me!txtField1.locked = true
  me!txtField2.locked = true
 ...
endif

You might even get fancy and change the background colors to indicate those lines that can be edited or not. I like white for can be edited and the minty green color for cannot be edited (me!txtField1.b ackcolor=xyz). :)

Jim

[FishVal]

You might even get fancy and change the background colors to indicate those lines that can be edited or not. I like white for can be edited and the minty green color for cannot be edited (me!txtField1.b ackcolor=xyz). :)

For a form in Datasheet or Continuos view it could be done only via conditional formatting which requires an additional field in the table indicating whether the record is locked or not.

Regards,
Fish

[jimatqsi]

@FishVal
Ah, you may be right about it requiring conditional formatting, I didn't realize that. But why would it require an additional field to indicate the locked status? The condition within the conditional formatting can still be a comparison of a data item on the row to the current date, or some other thing. It could be dynamic like that, it would not have to rely on a preset value in a lock flag. The preset value would be the date of the activity.

Jim

[FishVal]

@FishVal
Ah, you may be right about it requiring conditional formatting, I didn't realize that. But why would it require an additional field to indicate the locked status? The condition within the conditional formatting can still be a comparison of a data item on the row to the current date, or some other thing. It could be dynamic like that, it would not have to rely on a preset value in a lock flag. The preset value would be the date of the activity.

Jim

Ah well. I've overlooked that there is already a field ([transactiondate]) indicating record lock state. Additional field is certainly not needed.