Data Source Change Notifications
-
I've just been posed a challenge: to update a DataGrid on one client when another client changes the source table for that grid on a central database, all three connected on a standard TCP/IP network. Now I vaguely (probably incorrectly) remember something about earlier versions of ADO being able to detect changes in source data, but I may be senile already, so I said, "Yes, it's possible!"[1] Assuming there is no built-in way to detect these changes, I envisage several possible extrinsic solutions: 1. When other clients update the row, inform them it has changed since they read it. 2. Have each client broadcast the table/row ID to all others when they change it. 3. Have the database broadcast the table/row ID top all clients when it changes. The last two then involve interested clients fetching the current version of the row if necessary. It all seems rather messy, but this is not an uncommon problem, so what do I do? [1] It's not official work, so I'm allowed to do that. The DJ's took pills to stay awake and play for seven days. - Jim Morrison, Black Polished Chrome.
-
I've just been posed a challenge: to update a DataGrid on one client when another client changes the source table for that grid on a central database, all three connected on a standard TCP/IP network. Now I vaguely (probably incorrectly) remember something about earlier versions of ADO being able to detect changes in source data, but I may be senile already, so I said, "Yes, it's possible!"[1] Assuming there is no built-in way to detect these changes, I envisage several possible extrinsic solutions: 1. When other clients update the row, inform them it has changed since they read it. 2. Have each client broadcast the table/row ID to all others when they change it. 3. Have the database broadcast the table/row ID top all clients when it changes. The last two then involve interested clients fetching the current version of the row if necessary. It all seems rather messy, but this is not an uncommon problem, so what do I do? [1] It's not official work, so I'm allowed to do that. The DJ's took pills to stay awake and play for seven days. - Jim Morrison, Black Polished Chrome.
The solution depends upon how close you need to keep the synchronization. If 5-10 seconds is fine, you can just keep a TimeStamp on the rows. Every so often, send the client to request any rows that exceed it latest TimeStamp. It will usually return zero records and nothing needs to be done. This does require that rows be marked for deletion instead of physically deleted immediately. The other solution I have used is to create a service and all clients access the data through it. It is then easy to send update notices down the socket to each client. I try to avoid this solution since it will complicate future maintenance.
-
The solution depends upon how close you need to keep the synchronization. If 5-10 seconds is fine, you can just keep a TimeStamp on the rows. Every so often, send the client to request any rows that exceed it latest TimeStamp. It will usually return zero records and nothing needs to be done. This does require that rows be marked for deletion instead of physically deleted immediately. The other solution I have used is to create a service and all clients access the data through it. It is then easy to send update notices down the socket to each client. I try to avoid this solution since it will complicate future maintenance.
Michael Potter wrote:
The other solution I have used is to create a service and all clients access the data through it. It is then easy to send update notices down the socket to each client. I try to avoid this solution since it will complicate future maintenance.
Never mind complicating current development. Thanks, I think I'll look into the first solution. I suppose I could get a separate DataSet of changed rows and merge it into the DataSet behind the display, no? The DJ's took pills to stay awake and play for seven days. - Jim Morrison, Black Polished Chrome.