OleDbCommand.ExecuteReader Performance

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
I have a question regarding OleDbCommand.ExecuteReader.

From what I understand, ExecuteReader fetches rows on demand, on a row by
row basis.

What are the implications of using this method when your database is
accessed over the web? Won't it be terrible slow? The reason I ask this is
because it seems that each time I call OleDbDataReader.Read(), an HTTP
request is sent to the server and one row of data is returned.

Is there a better way of receiving user-defined chunks of data from
databases? I would rather not use OleDbDataAdapter as it is too slow.

Thanks.
 
Okay --- even in a web based environment, your server is what holds the
OleDbCommand instance, which is not communicating over HTTP to the
underlying database. So it's only as bad as the connection between your web
server and your oledb database is.

To get chunks of data instead - you can use DataTable/Dataset.


- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Hi, thanks for your reply.

I'm referring to a very simple configuration of a client application
connecting to a server that is placed in another country. The OleDbCommand
object is created on the client and the query is sent to the server over the
web.

The client is not a web-based application (which is probably what you were
referring to).
 
Strange what you say. I don't understand how and especially why the OleDb
provider will use Http as transport. I imagine that the OleDb provider can
not be so stupid, to use http in place of a custom protocol on top of tcp.
Maybe you use a http-tunneling application on top of tcp?!

Because the .NET OleDb provider is only a wrapper on top of the real OleDb
provider, you must research the behaviour of this provider. What is the
database you use?

Dumitru
 
In that sense, yes the data will go row by row, but I doubt a dataset will
be much better. The best way to optimize this would be have a process run
over there that streams you the compressed data here - or have a webservice
that runs over there. If you don't have that option, then oh well !!

BTW, it might or might not be row by row communciation over http - depends
on the exact database u have.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik
 
Back
Top