One thing you probably want to pay attention to is that, having local Access database requires your clients to install MDAC and JET, which is not part of .NET Framework runtime. If you're fine with it, fine.
If you're not fine, but still wants to cache previous results over slow connections, another possible solution is to save DataSet into XML. It won't be transactional, or easier to break than Access MDB, but your clients are free from installing MDAC and JET. If it's just a cache, it might do the job. -----Original Message----- From: The DOTNET list will be retired 7/1/02 [mailto:[EMAIL PROTECTED]] On Behalf Of Avi Nahir Sent: Monday, June 03, 2002 3:31 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] DataSets naive question Thanks for the feedback. Thinking this through I think Access has two advantages over an in-memory DataSet. First, it is persistant. It doesn't go away when the user turns off her computer. Second, data is stored and accessed in very efficient manner (i.e. indexes) which is even more critical when doing joins. So, when the server is doing the work and the returned result set is small than I understand I should use a dataset. For example, if the focus is on "Today's Top Ten Clients" and their orders, it makes sense to let SQL Server return 10 records for the clients + 1,000 records for their ordres, and process it in memory. IMHO, however, it makes more sense to use a local "helper" database when the following is true: You want to reduce the load on the database server. The data doesn't change a lot, so that sending it to clients pays for itself over time. A large (but not huge) amount of data is needed to answer user queries. The results are obtained through joins and aggregate funtions. In such a scenario I think it would make sense to let the local database process the queries. Does this make sense? Avi You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
