John DeSoi <[EMAIL PROTECTED]> writes: > > If you need data to propagate from the clients back to the server then > > things > > get more complicated. Even then you could side step a lot of headaches if > > you > > can structure the application in specific ways, such as guaranteeing that > > the > > clients can only insert, never update records. > > And even updates could be OK if the application can support the right > partitioning of the data and only do it one place at a time. With some kinds > of field based work it might be suitable to have global (read only) data > along > with data created in the field that is site/ client specific. As long as the > data collected in the field is not being updated on the master, it could > continue to be updated in the field and synced back to the master database.
Sure, though then you have to deal with what data to display on the client end. The most recently downloaded master data or the locally updated data? What about after you upload your local data when you're not sure whether the master data has been reconciled? Not impossible but it would be more work. But I find a surprisingly high fraction of applications are very amenable to being handled as insert-only. A medical application strikes me as something someone is all the more likely to be happy with an insert-only model. So instead of allowing having remote users to modify data directly you only allow them to "request" an update. Then when they look at the record it still makes logical sense to see the old data, along with their "requested" updates. Essentially, any replication system is based on insert-only queues. If you can design the application around that you avoid having to implement some sort of mapping to some hiding that. -- greg ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
