are you thinking of disconnected recordsets? if so the whole ADO.NET architecture operates on the disconnected model. Once you populate a dataset ADO.NET "disconnects" (sorry poor word here) from the underlaying database, and you work solely in memory. This is all good until you write back your changes to the database, then you have to start handling any changes that might have happened while you where playing with the dataBrenOS said:A database that can work on a local replica and then update at a chosen time to a central store.
It's not greatly important, but would be nice if I could take a look at a functional one, have googled for good long while but turned up nothing.