Re: DataView vs DataReader
I don't know what these sources are doing. It all depends on the purpose and
design of a system/component.
"Greg Burns" <greg_burns@DON T_SPAM_ME_hotma il.com> wrote in message
news:O7mlmq0lEH A.3760@TK2MSFTN GP12.phx.gbl...[color=blue]
> ACK
>
> But this still goes against most sources that I've seen.
>
> Greg
>
>
> "Marina" <someone@nospam .com> wrote in message
> news:u17jte0lEH A.2588@TK2MSFTN GP12.phx.gbl...[color=green]
> >I don't think a reusable component, should ever return a datareader to[/color][/color]
its[color=blue][color=green]
> > consumer. Because, again, you have to rely on the developer using your
> > component, to remember to close it in a timely fashion - or just to[/color][/color]
plain[color=blue][color=green]
> > close it.
> >
> > The component should open and close its own connection - so a connection
> > leak should never come from that component. It should then return the[/color][/color]
data[color=blue][color=green]
> > in a datatable or another data structure, and the consumer can then do
> > with
> > it whatever is necessary.
> >
> > Datareader can be more efficient, etc, etc - but an architecture[/color][/color]
component[color=blue][color=green]
> > should be careful or returning them, as again, this can often be a
> > problem.
> > You basically have to make sure that developers remember to close the
> > readers they get - because if not, you will quickly get a connection[/color][/color]
pool[color=blue][color=green]
> > is
> > out of available connections exception. Then you have to go track down
> > which
> > part of the code forgot to close the datareader. And believe me, I[/color][/color]
speak[color=blue][color=green]
> > of
> > this from experience.
> >
> > "Greg Burns" <greg_burns@DON T_SPAM_ME_hotma il.com> wrote in message
> > news:ullFF8rlEH A.3608@TK2MSFTN GP09.phx.gbl...[color=darkred]
> >> A datareader only keeps the connection open (if closed properly, and
> >> using
> >> CommandBehavior .CloseConnectio n) as long as it takes to read the data.
> >> Using a dataadapter to fill a dataset/dataview uses a datareader behind[/color]
> > the[color=darkred]
> >> scenes anyways.
> >>
> >> Although I haven't look in awhile, wasn't IBuySpy portal built using[/color]
> > mostly[color=darkred]
> >> datareaders returned from functions? I would ask around a little more
> >> before scraping the datareader solution. I always read the datareaders[/color]
> > where[color=darkred]
> >> more scalable.
> >>
> >> This all sounds wrong to me.
> >>
> >> My .02
> >> Greg
> >>
> >>
> >> "Marina" <someone@nospam .com> wrote in message
> >> news:OECuJ$qlEH A.712@TK2MSFTNG P09.phx.gbl...
> >> > DataReaders are meant for operations that involve reading all the[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> >> > right
> >> > away, and closing the reader. This is because the reader maintains[/color][/color][/color]
an[color=blue][color=green][color=darkred]
> >> > open
> >> > connection to the database - a valuable resource. I am not surprised
> >> > you
> >> > are
> >> > seeing this problem.
> >> >
> >> > Now, a dataview, has nothing to do with database access itself. It's
> >> > really
> >> > the datatable that can be used to place data into from the result of[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> >> > query. A dataview is another layer that can be put on top of that, to
> >> > provide a sorted or filtered view of the data in the underlying[/color][/color][/color]
table.[color=blue][color=green][color=darkred]
> >> >
> >> > I definitely recommend you go ahead and eliminate the datareader.
> >> > Datareader should never be returned from functions - as this requires[/color]
> > the[color=darkred]
> >> > consumer of the function to remember to close the data reader once it
> >> > is
> >> > no
> >> > longer needed. This isn't something anyone should rely on - not to
> >> > mention,
> >> > you never know how long the consumer of the function will keep that[/color]
> > reader[color=darkred]
> >> > open. It is no wonder you are experiencing all these problems.
> >> >
> >> >
> >> > "Mark" <mark@Z-Zvolution.nZt> wrote in message
> >> > news:chqfnl$i4j $1@lust.ihug.co .nz...
> >> >> Hi all, quick question [Please correct me where I am wong ;)], a[/color]
> > DataView[color=darkred]
> >> > is
> >> >> memory resident "view" of data in a data table therefore once
> >> >> populated
> >> > you
> >> >> can close the connection to the database. Garbage collection can[/color][/color][/color]
then[color=blue][color=green]
> > be[color=darkred]
> >> >> used to "clean up" the DataView once it is not referenced and will[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> >> >> effect the number of connections to the database.
> >> >>
> >> >> A DataReader on the other hand always maintains a connection to the
> >> > database
> >> >> and must be explicitly closed (Do not rely on garbage collection).
> >> >>
> >> >> Reason I am asking is that I have been give a heap of vb.net code[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> >> > there
> >> >> are numerous functions that return a DataReader (Causing all sorts[/color][/color][/color]
of[color=blue][color=green]
> > SQL[color=darkred]
> >> >> Timeout headaches, maximum connections reached etc). To solve this
> >> >> problem
> >> >> in the quickest amount of time I am thinking of replacing the[/color]
> > DataReaders[color=darkred]
> >> >> with DataViews so I can explicitly close the Database connection.
> >> >>
> >> >> Any other ideas (I would model the database via business objects and
> >> > return
> >> >> these but I really do not have the time as we need a "quote" quick[/color]
> > fix).[color=darkred]
> >> >>
> >> >> Thanks
> >> >> Mark
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>[/color]
> >
> >[/color]
>
>[/color]
I don't know what these sources are doing. It all depends on the purpose and
design of a system/component.
"Greg Burns" <greg_burns@DON T_SPAM_ME_hotma il.com> wrote in message
news:O7mlmq0lEH A.3760@TK2MSFTN GP12.phx.gbl...[color=blue]
> ACK
>
> But this still goes against most sources that I've seen.
>
> Greg
>
>
> "Marina" <someone@nospam .com> wrote in message
> news:u17jte0lEH A.2588@TK2MSFTN GP12.phx.gbl...[color=green]
> >I don't think a reusable component, should ever return a datareader to[/color][/color]
its[color=blue][color=green]
> > consumer. Because, again, you have to rely on the developer using your
> > component, to remember to close it in a timely fashion - or just to[/color][/color]
plain[color=blue][color=green]
> > close it.
> >
> > The component should open and close its own connection - so a connection
> > leak should never come from that component. It should then return the[/color][/color]
data[color=blue][color=green]
> > in a datatable or another data structure, and the consumer can then do
> > with
> > it whatever is necessary.
> >
> > Datareader can be more efficient, etc, etc - but an architecture[/color][/color]
component[color=blue][color=green]
> > should be careful or returning them, as again, this can often be a
> > problem.
> > You basically have to make sure that developers remember to close the
> > readers they get - because if not, you will quickly get a connection[/color][/color]
pool[color=blue][color=green]
> > is
> > out of available connections exception. Then you have to go track down
> > which
> > part of the code forgot to close the datareader. And believe me, I[/color][/color]
speak[color=blue][color=green]
> > of
> > this from experience.
> >
> > "Greg Burns" <greg_burns@DON T_SPAM_ME_hotma il.com> wrote in message
> > news:ullFF8rlEH A.3608@TK2MSFTN GP09.phx.gbl...[color=darkred]
> >> A datareader only keeps the connection open (if closed properly, and
> >> using
> >> CommandBehavior .CloseConnectio n) as long as it takes to read the data.
> >> Using a dataadapter to fill a dataset/dataview uses a datareader behind[/color]
> > the[color=darkred]
> >> scenes anyways.
> >>
> >> Although I haven't look in awhile, wasn't IBuySpy portal built using[/color]
> > mostly[color=darkred]
> >> datareaders returned from functions? I would ask around a little more
> >> before scraping the datareader solution. I always read the datareaders[/color]
> > where[color=darkred]
> >> more scalable.
> >>
> >> This all sounds wrong to me.
> >>
> >> My .02
> >> Greg
> >>
> >>
> >> "Marina" <someone@nospam .com> wrote in message
> >> news:OECuJ$qlEH A.712@TK2MSFTNG P09.phx.gbl...
> >> > DataReaders are meant for operations that involve reading all the[/color][/color][/color]
data[color=blue][color=green][color=darkred]
> >> > right
> >> > away, and closing the reader. This is because the reader maintains[/color][/color][/color]
an[color=blue][color=green][color=darkred]
> >> > open
> >> > connection to the database - a valuable resource. I am not surprised
> >> > you
> >> > are
> >> > seeing this problem.
> >> >
> >> > Now, a dataview, has nothing to do with database access itself. It's
> >> > really
> >> > the datatable that can be used to place data into from the result of[/color][/color][/color]
a[color=blue][color=green][color=darkred]
> >> > query. A dataview is another layer that can be put on top of that, to
> >> > provide a sorted or filtered view of the data in the underlying[/color][/color][/color]
table.[color=blue][color=green][color=darkred]
> >> >
> >> > I definitely recommend you go ahead and eliminate the datareader.
> >> > Datareader should never be returned from functions - as this requires[/color]
> > the[color=darkred]
> >> > consumer of the function to remember to close the data reader once it
> >> > is
> >> > no
> >> > longer needed. This isn't something anyone should rely on - not to
> >> > mention,
> >> > you never know how long the consumer of the function will keep that[/color]
> > reader[color=darkred]
> >> > open. It is no wonder you are experiencing all these problems.
> >> >
> >> >
> >> > "Mark" <mark@Z-Zvolution.nZt> wrote in message
> >> > news:chqfnl$i4j $1@lust.ihug.co .nz...
> >> >> Hi all, quick question [Please correct me where I am wong ;)], a[/color]
> > DataView[color=darkred]
> >> > is
> >> >> memory resident "view" of data in a data table therefore once
> >> >> populated
> >> > you
> >> >> can close the connection to the database. Garbage collection can[/color][/color][/color]
then[color=blue][color=green]
> > be[color=darkred]
> >> >> used to "clean up" the DataView once it is not referenced and will[/color][/color][/color]
not[color=blue][color=green][color=darkred]
> >> >> effect the number of connections to the database.
> >> >>
> >> >> A DataReader on the other hand always maintains a connection to the
> >> > database
> >> >> and must be explicitly closed (Do not rely on garbage collection).
> >> >>
> >> >> Reason I am asking is that I have been give a heap of vb.net code[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> >> > there
> >> >> are numerous functions that return a DataReader (Causing all sorts[/color][/color][/color]
of[color=blue][color=green]
> > SQL[color=darkred]
> >> >> Timeout headaches, maximum connections reached etc). To solve this
> >> >> problem
> >> >> in the quickest amount of time I am thinking of replacing the[/color]
> > DataReaders[color=darkred]
> >> >> with DataViews so I can explicitly close the Database connection.
> >> >>
> >> >> Any other ideas (I would model the database via business objects and
> >> > return
> >> >> these but I really do not have the time as we need a "quote" quick[/color]
> > fix).[color=darkred]
> >> >>
> >> >> Thanks
> >> >> Mark
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>[/color]
> >
> >[/color]
>
>[/color]
Comment