True. I’ve used a scheme like that in other cases and it would be OK here because this is a small database. A solution like that doesn’t scale well or work well if the database is running over WAN. The milliseconds of delay over WAN start to add up. And it can really up the amount of network chatter. I’m really using this as an opportunity to try to find a solution that doesn’t require all that network chatter.
I have worked out a primitive implementation of the idea Marie-Sophie suggested here:
If this were a v18 project I think I could build a subform widget that could be dropped onto a form and initialized with the entity to monitor and from there manage everything. In v17 I couldn’t make that work. So I went with a solution specific to the form. That is a button named delta_entity and labeled “Refresh”. I enabled the On Timer event and set it for 1 second.
It’s invisible by default.
The form method manages displaying it:
OBJECT SET VISIBLE(*;"delta_entity";$entityDelta)
Form.e is the entity, if one is selected. The button code is simply
It works great so far catching changes on records right away. On this form I save each time a change is made so the user never has lots of unsaved changed. And this lets the On Timer go by without interrupting the user during input.
The only part I wish I could reduce is the
That’s going to run once a second from every workstation that has this form open. But perhaps it’s not such a big load? Perhaps the getStamp() method is optimized in a way to reduces the network load? As I say this is fine for small databases but I have doubts it would be good on an installation with hundreds of simultaneous users.