Thanks, Greg. I undestand this "in memory" issue. However, what I'm thinking is: You are supposed to take the data from a 'big' (say, SQL Server) database, work on it in memory using a Dataset, and then return the modifications. But what if, instead, you take the data, store it in an Access (Jet) database, work on it (using possibly ADO.Net Command objects or dataset) and then, at your leisure, return the modifications to the big database?
The basic thing that bugs me: Being "in memory" is not enough merit for a technology! I must be missing something. What? What is the advantage of using an in memory Dataset as opposed to the scenario above? On Sun, 2 Jun 2002 08:26:31 -0500, Greg Ward <[EMAIL PROTECTED]> wrote: >> Should I use a Dataset or a local MS-Access database? >> >> The basis for my question: The dataset is touted as an in-memory database: >> It has schema, data, relations, filtering, sorting, and persistence >> (through XML serialization). So, if it is "like" a database, why not >> use "the real thing"? >> >> What is the crux of the difference between a local database and a dataset? > >Well the big difference is that the dataset exists only in memory. You could >think of it as similiar to a disconnected recordset. You fill the dataset with >the data, view and manipulate as necessary, then save the data back to the >database. If you had no database then of course you'd have no data to fill the >dataset with nor would you have a place to store changes. > >Greg Ward >************************************ >www.VB-FAQ.com >VB Developer's FAQ site >************************************ You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
