Record Marking & Multi-User considerations...

[SNusa]

I can't test this locally (with 2 forms open) because of how "focus" on the forms effects browse/control refreshing...

Given the limitations of not having any support for transactional processing.....
To avoid the unlikely possibility of 2 users trying to simultaneously update a record (which in turn requires the update of 2 other related tables), I'm considering using the dbf's "selected field" (by marking/un-marking records.) I've noticed that this field seems to update on both forms without moving off a record within a browse. (on the same PC at least)

Question is: When a record is marked by one user, does the status of this immediately appear on the other user's browse on an open (focused) form?
(I can't tell/test this myself because when the second form doesn't have focus, updates don't display until I switch to the other form.)

I suppose it doesn't really matter, because that's just the display, and this data/information (displayed or otherwise) is in the dbf file itself? (If so, using "this.Is_Marked()" will return "current status" regardless of what is displayed/refreshed on the visible form/browse.) ~ The related question is, within a browse (on a form), exactly how/when is this "marked data field" referenced/updated? Is it "cached?" (Or is the actual status checked the instant a user tries to set the record to marked?)

Also, if a project were to ever be converted to a flavor of MariaDB (the mySQL variant): Is using this method ("marking" the dbf's "selected field") even a good idea in the first place?
Or should I add another field to the table and have the browse "commit" the value of the line item (via a browse button "event event") back to the table immediately when it is selected?
(Here again, the same question/problem arises. If there is any browse "data caching" going on, I'll have to have a browse button "event event" process the selection and query the data from the underlying table.)

The thing is: I do not want the second user to be able to successfully mark a record that is presently marked by another user.
My initial idea is to use "this.Is_Marked()" when double clicking the browse record (to check status) immediately before applying "this.mark_Record()."
(And un-mark each users marked records once all operations are performed for that user.)

Note: DBF's in use here, Referential integrity NOT used.

PS: Part of my "confusion" here is I am under the assumption that with the exception of the "marked/unmarked" status, actual table writes (within an embedded browse field on a form) are TYPICALLY (without code) written to the the table when the the row changes/looses focus. And similarly, the browse data is TYPICALLY (without code) populated when the form opens/moves to another record etc? ~ Hope that makes sense.

[SNusa]

Re: Record Marking & Multi-User considerations...

Nobody has an answer to this?

I'm considering using the dbf's "selected field" (by "marking/un-marking" records. ~ And testing for the status (this.Is_Marked()) on the form/browse double-click event, which is also performing the marking/un-marking action. (So that two different users cannot even try to update a record at the same time.)

Question is: When a record is marked by one user, does the status of this immediately appear on the other user's browse on an open (focused) form?
(I can't tell/test this myself because when the second form doesn't have focus, updates don't display until I switch to the other form.)

[DaveM]

Re: Record Marking & Multi-User considerations...

Robert,

Marking records is across all users. I don't think it can work for just one or a group. I have not used marking since I went away from single users.

I insert a field(usually logical) in a table and mark the field according to need. This is usually so that field is included in a report and clear the field after the report or other is done.

[SNusa]

Re: Record Marking & Multi-User considerations...

Hi Dave;

Across all users is a good thing. That's how I'm trying to use it. (To prohibit a second user from trying even trying to select the same record.)

I've got a neat little form for selecting multiple items for "batch processing." As the user double clicks on an item, it adds it to an enumerated list.
If the user submits the form, this enumerated lists processes two other child tables as well as the records in this table. (Child tables are processed via a call to a global function which receives this enumerated list (character variable) as one of the parameters.

What I want to do is ensure that no two users on a multi-user system could possibly generate their respective enumerated lists with any items (from the same table) in common.
Also, I suspect that "marking records" in this context is an Alpha/.dbf thing only, right?

Assuming this to be true:
The only other way (of doing the same thing compatible with a SQL backend) that I can think of is to use a "check-out, check-in" method. (And using an extra field for temporarily storing the current user's ID in the table. ~ And then clearing this value once the records [parent records] are all processed.) Note: Once the parent records are processed, they will never re-appear in this list for selection again. (This assignment, once committed is a "one shot deal.")

Does the logic above make sense to you? (adding the extra field)