Re: ASP.NET data access

DataReaders are far more performant (mrrr, is that a word?) than
DataSets if all you are doing is _reading_ data from a DB. But if you have
to do any editing you'll probably want to use a DataSet. Just be sure to be
kind to the .NET Framework and call Dispose() on the DataSet object when you
no longer need it (don't just let it fall out of scope).

-- Sean M

"Elton W" <EltonW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:76A94184-5A0E-4AEB-BD68-2542DB9535E9@xxxxxxxxxxxxxxxx
> Hi DwC,
>
> Since you need disconnected data (DataSet), datareader is not necessary.
> It's better to use dataadapter to fill dataset. And if your individual
> Dataset is from single DB table, you don't have to create your own
inserts,
> updates and deletes methods. You can use dataadapter (combining with
> commandbuilder) to fill dataset. Then you can use dataset.Update method to
> update data back to DB (commandbuilder can automatically generate
> corresponding update (insert, delete, or update) command(s).
>
> HTH
> Elton Wang
> elton_wang@xxxxxxxxxxx
>
> "DwC" wrote:
>
> > Hi,
> >
> > We have a ms access database that we will be using to develop a website
> > which would have fairly low usage levels.
> >
> > We have some experience with windows apps but not so much with asp.net
> > projects. We have used ADO datasets previously for a windows application
> > that we developed where the entire db was loaded into the dataset at the
> > beginning of the application and the user made changes to the dataset
> > which was then saved back to the db when the app was shut down.
> >
> > We now have to develop the asp app and we can't quite work out which
> > technique we should be using:
> >
> > 1 - the original technique which seems like a huge waste of resources
> > for a web app - loading the data from the db into the dataset each time
> > the db access class is created. Which means that when data is required
> > it is returned from the dataset saving a connection, but has used a heap
> > of resources loading from the db in the first place. This also raises
> > the question of when to synchronise the dataset and the db.
> >
> > 2 - using datareaders to directly access the data required. When the
> > page loads it creates a db access class which has a connection and
> > methods which when called open the connection, pack the data into the
> > return object (which could be strings, collection, or user defined)
> > using the datareader and then close the connection and return the packed
> > object. We would in this case have insert methods which would then use
> > inserts, updates and deletes to directly update the database.
> >
> > 3 - using datasets from each method in the db access class instead of
> > one large dataset. So the methods would be like:
> > private DataSet GetProducts() etc..
> > instead of one large dataset. We would then have a update or delete
> > method or whatever which would take back a dataset and make the changes
> > directly to the database. The problem that this technique seems to have
> > is that you are creating a dataset in each method, which is failur
> > repetitive and may only contain a few rows.
> >
> > If anyone can help by totally ruling out any of these options or
> > providing different techniques it would be greatly appreciated. I have
> > done some research about this but haven't been able to find a really
> > good resource that explains the preferred technique for a web app.
> >
> > Thanks in advance.
> >


.

Relevant Pages

  • RE: ASP.NET data access
    ... Since you need disconnected data, datareader is not necessary. ... > which was then saved back to the db when the app was shut down. ... > 1 - the original technique which seems like a huge waste of resources ... > the db access class is created. ...
    (microsoft.public.dotnet.framework.aspnet)
  • ASP.NET data access
    ... We have used ADO datasets previously for a windows application that we developed where the entire db was loaded into the dataset at the beginning of the application and the user made changes to the dataset which was then saved back to the db when the app was shut down. ... Which means that when data is required it is returned from the dataset saving a connection, but has used a heap of resources loading from the db in the first place. ... We would in this case have insert methods which would then use inserts, updates and deletes to directly update the database. ... The problem that this technique seems to have is that you are creating a dataset in each method, which is failur repetitive and may only contain a few rows. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP.NET data access
    ... Although datareader has good performance, using it to fill dataset maybe not. ... "Sean M" wrote: ... >>> which was then saved back to the db when the app was shut down. ... >>> it is returned from the dataset saving a connection, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: SQL Conn: open/close or keep open?
    ... If you have a DataReader open and you are reading through the ... > exclusive access to the connection and you cannot use the connection ... > even a single user WinForms app would need more than one connection. ... > user opens your app and then goes on vacation for a week, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Slow first connection to SQL Server
    ... I created a windows forms app and used the same ... technique to connect and it does not show that problem. ... >> It is the connection itself that is the problem. ...
    (microsoft.public.dotnet.framework.aspnet)