J
Jesse Aufiero
I'd like to develop a client-server application where the users (.Net 2003
application) can modify data in the database (sql server 2005), and all
other users will see those changes in near real time. This kind of
architecture will require that the client applications periodically (every
second or two) poll the server to see if they are up to date. If they are
not, they pull the appropriate fresh data from the server. The clients can
then view the fresh data (in grids, charts, and pivot tables) in a
disconnected fashion until the next change triggers them all to refresh.
I intend to have a single row in one of my database tables provide the
clients with a 'change type' and 'change number' to facilitate this near
real time synchronization. If Client A makes a change to his copy of the
data, his changes are written back to the database and the 'change type' and
number are updated. The other clients will detect this change, and refresh
themselves.
Upon refresh, I think that merging the new data with the client's existing
datasets/tables will be necessary, since the display controls (grids, pivot
tables, etc.) in the UI that display the data should not flicker or lose row
focus when the refresh occurs. In fact, it's critical that both the polling
for changes and the refresh be completely unobtrusive. I'd rather the
program not even 'pause' at all during the refresh. Perhaps a background
process is needed here.
I'd really like to avoid re-inventing the wheel, and I am not an expert in
ADO.NET 2003, so I'm looking to see if anyone has seen this type of
architecture before, and if there are samples/'patterns' out there that can
steer me and save me some time. I'd also be interested in speaking with
someone who may want to consult me in how to go about designing such an
architecture ($).
Of particular interest to me is how to handle concurrency and make use of
transactions, given that Client A may make changes to multiple rows or
tables (with parent-child relationships) and need to write those changes
back to the server as one 'package', to be detected by the other clients
and, refreshed as a 'package'.
Thanks!
application) can modify data in the database (sql server 2005), and all
other users will see those changes in near real time. This kind of
architecture will require that the client applications periodically (every
second or two) poll the server to see if they are up to date. If they are
not, they pull the appropriate fresh data from the server. The clients can
then view the fresh data (in grids, charts, and pivot tables) in a
disconnected fashion until the next change triggers them all to refresh.
I intend to have a single row in one of my database tables provide the
clients with a 'change type' and 'change number' to facilitate this near
real time synchronization. If Client A makes a change to his copy of the
data, his changes are written back to the database and the 'change type' and
number are updated. The other clients will detect this change, and refresh
themselves.
Upon refresh, I think that merging the new data with the client's existing
datasets/tables will be necessary, since the display controls (grids, pivot
tables, etc.) in the UI that display the data should not flicker or lose row
focus when the refresh occurs. In fact, it's critical that both the polling
for changes and the refresh be completely unobtrusive. I'd rather the
program not even 'pause' at all during the refresh. Perhaps a background
process is needed here.
I'd really like to avoid re-inventing the wheel, and I am not an expert in
ADO.NET 2003, so I'm looking to see if anyone has seen this type of
architecture before, and if there are samples/'patterns' out there that can
steer me and save me some time. I'd also be interested in speaking with
someone who may want to consult me in how to go about designing such an
architecture ($).
Of particular interest to me is how to handle concurrency and make use of
transactions, given that Client A may make changes to multiple rows or
tables (with parent-child relationships) and need to write those changes
back to the server as one 'package', to be detected by the other clients
and, refreshed as a 'package'.
Thanks!