Data distribution and sync RRS feed

  • Question

  • Hi:

    Am looking for help,pointers, references to help me architect an App as described below:

    1. A table (around 50k rows) is distributed to multiple Intranet users (plan - use a disconnected dataset)

    2. A user can edit only rows assigned to him/her (plan - control this with code)

    3. Each user should receive changes from other users in near real-time (this is where I am not sure what to do).


    I would like to Push changes from the server to all users. (What's the dotNet version of Active Channel? Or would Ajax dotNet help? Any other options? Or would I be forced to have a scheduled poll from Client to server?)

    I would like to push only rows and fields that have changed, and not the entire data. (How can I do that with a dataset?)




    Friday, December 28, 2007 11:08 AM

All replies

  • This is not something you do with Ajax or Active Channel you need some good data compare tool or replication both are expensive and there is no cheap solution when users are making changes that needs to be synchronized back to your RDBMS. Express can only be a subscriber in a replication so if all your users are using Express you need a compare tool, both Microsoft and Redgate sells such tools. The other option is to use full licensed SQL Servers to do replication of the data from the users.

    Friday, December 28, 2007 4:18 PM
  • All my users are connected to an RDBMS. Each person can edit only his data, but can see a readonly copy of others' data. So whenever an update is fired on the DB, I would like to send updated row to all readers.

    I was just thinking of multicasting the updates with something like ActiveChannel.

    Users just have a local dataset for client side processing, and whenever they save an update, their Changes get sent to the RDBMS by the usual Adapter and dataset methods.

    I think I mis-communicated my problem, and I am sure I dont want a replication solution. :-)

    All I am looking for, is a way to push updated rows from server to client.



    Monday, December 31, 2007 12:44 PM
  • (All I am looking for, is a way to push updated rows from server to client.)


    When you are pushing changes to RDBMS in an update you need replication or compare tool because of data integrity, if your users are not many you can give each a seperate table then you will not need replication but if all are changing the same data you need replication


    Monday, December 31, 2007 3:01 PM
  • Why in the world would he need replication? The client does not have a database ... the client is only working with a disconnected DataSet. And he said that each user is changing their own data and do not touch anyone else's data.


    OP, as far as pushing data from server to client, I doubt if I can help you with that (having never had to do it), but I'm sure there are some options available to you. Maybe have the client app periodically query the database to pull rather than push (I'm sure pushing is preferable though).


    I hope someone else might have some ideas for you.

    Wednesday, January 2, 2008 12:37 AM
  • (The client does not have a database ... the client is only working with a disconnected DataSet.)


    If the changes are pushed back in realtime disconnected dataset is not really relevant because all the changes and updates must be valid for you to update the database.  I also gave the OP a clean option give each user a table so all the changes and updates can be clean without replication. 


    Wednesday, January 2, 2008 1:14 AM
  • I would look into using PeerChannel from WCF.  You can broadcast your changes to all the clients using the PeerChannel.  You might also want to send the updates directly to the server using another WCF binding with the server.  If the server updates the data properly, then broadcast it to the clients.  There are examples in the Windows SDK that might help (Check out the peer chat samples).  You might also want to check out the latest CTP of Sync Services 2.  There is a peer to peer sync mechanism, but this might not be exacally what you want.


    Wednesday, January 2, 2008 1:20 AM
  • >>If the changes are pushed back in realtime disconnected dataset is not really relevant because all the changes and updates must be valid for you to update the database<<


    Not sure what you're getting at here. Of course all the changes must be valid to update the database!! Nobody is implying that they aren't.


    Are you disagreeing with the whole disconnected DataSet concept? Because, if so, then you're way out in left field. That's the whole definition of a DataSet, IMHO ... it's a disconnected look at the data on your database.


    You make changes to the DataSet, then update your database with those changes. If there is the possiblity that someone else may be updating those same rows in your database, then you must "refresh" your DataSet ... still nothing wrong with this scenario. And the OP said that no one else touches the user's data other than the user, so that doesn't even apply in this case.

    Wednesday, January 2, 2008 1:25 AM
  • 1. A table (around 50k rows) is distributed to multiple Intranet users (plan - use a disconnected dataset)

    This in not one related to the disconnected nature of a dataset when one copy us used but when it is distributed to multiple users who will make changes to one table it is different.


    Wednesday, January 2, 2008 1:40 AM
  • Hmmm ... good point ... guess I missed that. Sorry.


    Still, if every user is only updating his own data, there won't be any overlap of what gets updated on the database. So, it can still work.

    Wednesday, January 2, 2008 1:45 AM
  • 50,000 by 10 users 500,000 disconnected base rows before changes which will be converted back to the 50,000 in realtime.  This is more complicated than 1,000 users with the 50,000 rows in one dataset which is just simple updates.

    Wednesday, January 2, 2008 2:29 AM
  • Thanks for all the responses.

    Am trying out some of the suggestions.

    Just a few clarifications.

    1. I am not worried about collisions. Each person is allocated a unique subset of rows and can only edit these rows. So a Last Update Wins scenario is good enough. I dont need multiple tables or Replication, am quite sure of that much :-)


    2. Each user can however see (Read-only) the rows allocated to all other users.

    3. Each user should be able to see others' changes in near real-time.


    It is easy enough to develop this if client pulled for updates periodically. However, I think pushing updates would be cleaner, faster, cheaper. If Client Pulls, then he probably gets the whole dataset again (unless I set up some timestamping logic). If server pushes, it could multicast, and it could only send out updated rows, and it has less queries to serve.


    Thnaks again, and will try those SyncChannel and other options suggested.




    Thursday, January 3, 2008 11:46 AM