"Jesse Aufiero" <jaufi***@moaboil.com> wrote in message
news:edbx5CteHHA.1240@TK2MSFTNGP04.phx.gbl...
> 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!
>

"Jesse Aufiero" <jaufi***@moaboil.com> wrote in message
news:edbx5CteHHA.1240@TK2MSFTNGP04.phx.gbl...
> 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!
>

"Jesse Aufiero" <jaufi***@moaboil.com> schreef in bericht
news:edbx5CteHHA.1240@TK2MSFTNGP04.phx.gbl...
> 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!
>