Re: client-server app where data is disconnected, but stays fresh
- From: "William \(Bill\) Vaughn" <billvaRemoveThis@xxxxxxxxx>
- Date: Mon, 9 Apr 2007 12:01:23 -0700
While this is not an uncommon design request, it exposes a number of fairly
involved issues. Yes, perhaps we can talk about this offline. Please send me
some mail privately and we can work on the issue. While my schedule is
pretty full, I might be able to work you in for a few hours.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Visit www.hitchhikerguides.net to get more information on my latest book:
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook)
-----------------------------------------------------------------------------------------------------------------------
"Jesse Aufiero" <jaufiero@xxxxxxxxxxx> wrote in message
news:edbx5CteHHA.1240@xxxxxxxxxxxxxxxxxxxxxxx
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!
.
- References:
- client-server app where data is disconnected, but stays fresh
- From: Jesse Aufiero
- client-server app where data is disconnected, but stays fresh
- Prev by Date: client-server app where data is disconnected, but stays fresh
- Next by Date: Re: client-server app where data is disconnected, but stays fresh
- Previous by thread: client-server app where data is disconnected, but stays fresh
- Next by thread: Re: client-server app where data is disconnected, but stays fresh
- Index(es):
Relevant Pages
|
