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.
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.
Comment