Hi

I am using a strongly typed dataset created by vs 2008. I have added a query
to select next record to the data adapter as below;

SELECT TOP 1 <field list>
FROM MyTable
WHERE (ID > ?)
ORDER BY ID

? is replaced by the ID of the current record.

My problem is when I fill using this query there is a noticeable about half
a second delay before data is retrieved. Is there any way to improve the
performance of this query?

Thanks

Regards

Re: ado.net data access performance by Mr

Mr
Fri Feb 29 21:18:50 CST 2008


"John" <John@nospam.infovis.co.uk> wrote in message
news:OwLNIG0eIHA.5984@TK2MSFTNGP06.phx.gbl...
> Hi
>
> I am using a strongly typed dataset created by vs 2008. I have added a
> query to select next record to the data adapter as below;
>
> SELECT TOP 1 <field list>
> FROM MyTable
> WHERE (ID > ?)
> ORDER BY ID
>
> ? is replaced by the ID of the current record.
>
> My problem is when I fill using this query there is a noticeable about
> half a second delay before data is retrieved. Is there any way to improve
> the performance of this query?
>

http://www.devx.com/vb2themax/article/19887/1954>


Re: ado.net data access performance by Michel

Michel
Sat Mar 01 04:33:52 CST 2008

Use a datareader and ditch all the overhead of the drag and drop controls if
it is speed you are after


Michel




"John" <John@nospam.infovis.co.uk> schreef in bericht
news:OwLNIG0eIHA.5984@TK2MSFTNGP06.phx.gbl...
> Hi
>
> I am using a strongly typed dataset created by vs 2008. I have added a
> query to select next record to the data adapter as below;
>
> SELECT TOP 1 <field list>
> FROM MyTable
> WHERE (ID > ?)
> ORDER BY ID
>
> ? is replaced by the ID of the current record.
>
> My problem is when I fill using this query there is a noticeable about
> half a second delay before data is retrieved. Is there any way to improve
> the performance of this query?
>
> Thanks
>
> Regards
>
>



Re: ado.net data access performance by John

John
Sat Mar 01 07:38:29 CST 2008

If I use datareader to replace "fill" my form controls, what method can I
use to update the values back to db?

Thanks

Regards

"Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
news:eH6gwe4eIHA.748@TK2MSFTNGP04.phx.gbl...
> Use a datareader and ditch all the overhead of the drag and drop controls
> if it is speed you are after
>
>
> Michel
>
>
>
>
> "John" <John@nospam.infovis.co.uk> schreef in bericht
> news:OwLNIG0eIHA.5984@TK2MSFTNGP06.phx.gbl...
>> Hi
>>
>> I am using a strongly typed dataset created by vs 2008. I have added a
>> query to select next record to the data adapter as below;
>>
>> SELECT TOP 1 <field list>
>> FROM MyTable
>> WHERE (ID > ?)
>> ORDER BY ID
>>
>> ? is replaced by the ID of the current record.
>>
>> My problem is when I fill using this query there is a noticeable about
>> half a second delay before data is retrieved. Is there any way to improve
>> the performance of this query?
>>
>> Thanks
>>
>> Regards
>>
>>
>
>



Re: ado.net data access performance by Mr

Mr
Sat Mar 01 08:28:19 CST 2008


"John" <John@nospam.infovis.co.uk> wrote in message
news:%237BXFG6eIHA.1132@TK2MSFTNGP06.phx.gbl...
> If I use datareader to replace "fill" my form controls, what method can I
> use to update the values back to db?
>
> Thanks
>

You use an ADO.Net Command object that works with such databases such as SQL
Server, Oracle, etc, etc and do record inserts or updates, using a T-SQL
statement, no dataset and manual of the fly.


Re: ado.net data access performance by Michel

Michel
Sat Mar 01 10:26:26 CST 2008

You can use a command object for updating , inserting , delete just as easy
with ACCESS

Michel






"Mr. Arnold" <MR. Arnold@Arnold.com> schreef in bericht
news:O9inQi6eIHA.4728@TK2MSFTNGP03.phx.gbl...
>
> "John" <John@nospam.infovis.co.uk> wrote in message
> news:%237BXFG6eIHA.1132@TK2MSFTNGP06.phx.gbl...
>> If I use datareader to replace "fill" my form controls, what method can I
>> use to update the values back to db?
>>
>> Thanks
>>
>
> You use an ADO.Net Command object that works with such databases such as
> SQL Server, Oracle, etc, etc and do record inserts or updates, using a
> T-SQL statement, no dataset and manual of the fly.



Re: ado.net data access performance by Mr

Mr
Sat Mar 01 11:47:05 CST 2008


"Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
news:%23EY0xj7eIHA.3940@TK2MSFTNGP05.phx.gbl...
> You can use a command object for updating , inserting , delete just as
> easy with ACCESS
>

I didn't say you couldn't. So just what is your problem?


Re: ado.net data access performance by William

William
Sat Mar 01 13:52:58 CST 2008

This query requires that the entire table be ordered before the ordinal is
returned. I would look at the query plan in SSMS to see what kind of plan is
being generated. I would also make sure that there are supporting indexes on
the ID column. Fill is not the best choice here as you don't need to return
a rowset but an ordinal. For this reason, I would use the
Command.ExecuteScalar. This returns a single value (as an object).

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
"John" <John@nospam.infovis.co.uk> wrote in message
news:OwLNIG0eIHA.5984@TK2MSFTNGP06.phx.gbl...
> Hi
>
> I am using a strongly typed dataset created by vs 2008. I have added a
> query to select next record to the data adapter as below;
>
> SELECT TOP 1 <field list>
> FROM MyTable
> WHERE (ID > ?)
> ORDER BY ID
>
> ? is replaced by the ID of the current record.
>
> My problem is when I fill using this query there is a noticeable about
> half a second delay before data is retrieved. Is there any way to improve
> the performance of this query?
>
> Thanks
>
> Regards
>
>


Re: ado.net data access performance by Michel

Michel
Sat Mar 01 14:05:39 CST 2008

Based on the question and the SQL statement

SELECT TOP 1 <field list>
FROM MyTable
WHERE (ID > ?)
ORDER BY ID

? is used in ACCESS SQL where @varname is used for other databases

I know for a fact that the TS is using ACCESS and you forgot to mention it
in your answer becides all the other databases you did mention the TS migh
have thought that it is not possible with ACCESS.

So i just wanted to point out that a command object could also be used icw
with ACCESS


> I didn't say you couldn't. So just what is your problem?

And problems ......

I don`t have anny problems with a person who is probably a professional like
me , who is devoting his probably spare time to help others in newsgroups
like these to point them in the right direction or to solve the problems of
these people And all of this for ........ yes for what ?

Well i have the highest respect for those people and value them as "must be
good people" and if i encounter them in a thread of answers i see there
postings not as an atack on my answer but as a additive to the discussion
" probably it wasn`t clear enough , or i was understood wrong ".

If you were asking about "personal" problems well i have and had plenty of
them but as your name is not Dr Phil i wil not bother you with them :-)

regards

Michel Posseth





"Mr. Arnold" <MR. Arnold@Arnold.com> schreef in bericht
news:u2kGXR8eIHA.5296@TK2MSFTNGP05.phx.gbl...
>
> "Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
> news:%23EY0xj7eIHA.3940@TK2MSFTNGP05.phx.gbl...
>> You can use a command object for updating , inserting , delete just as
>> easy with ACCESS
>>
>
> I didn't say you couldn't. So just what is your problem?



Re: ado.net data access performance by Michel

Michel
Sat Mar 01 14:14:24 CST 2008

Ahum :-(

after rereading i am not so sure annymore about this

"> I know for a fact that the TS is using ACCESS


But okay you got the point i hope :-)

Michel



"Michel Posseth [MCP]" <MSDN@posseth.com> schreef in bericht
news:u5Fi4d9eIHA.1212@TK2MSFTNGP05.phx.gbl...
> Based on the question and the SQL statement
>
> SELECT TOP 1 <field list>
> FROM MyTable
> WHERE (ID > ?)
> ORDER BY ID
>
> ? is used in ACCESS SQL where @varname is used for other databases
>
> I know for a fact that the TS is using ACCESS and you forgot to mention
> it in your answer becides all the other databases you did mention the TS
> migh have thought that it is not possible with ACCESS.
>
> So i just wanted to point out that a command object could also be used
> icw with ACCESS
>
>
>> I didn't say you couldn't. So just what is your problem?
>
> And problems ......
>
> I don`t have anny problems with a person who is probably a professional
> like me , who is devoting his probably spare time to help others in
> newsgroups like these to point them in the right direction or to solve the
> problems of these people And all of this for ........ yes for what ?
>
> Well i have the highest respect for those people and value them as "must
> be good people" and if i encounter them in a thread of answers i see there
> postings not as an atack on my answer but as a additive to the discussion
> " probably it wasn`t clear enough , or i was understood wrong ".
>
> If you were asking about "personal" problems well i have and had plenty of
> them but as your name is not Dr Phil i wil not bother you with them :-)
>
> regards
>
> Michel Posseth
>
>
>
>
>
> "Mr. Arnold" <MR. Arnold@Arnold.com> schreef in bericht
> news:u2kGXR8eIHA.5296@TK2MSFTNGP05.phx.gbl...
>>
>> "Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
>> news:%23EY0xj7eIHA.3940@TK2MSFTNGP05.phx.gbl...
>>> You can use a command object for updating , inserting , delete just as
>>> easy with ACCESS
>>>
>>
>> I didn't say you couldn't. So just what is your problem?
>
>



Re: ado.net data access performance by John

John
Sat Mar 01 15:00:26 CST 2008

Hi Bill

I have skipped all the fields as there were too many to list. This is the
sql which I have added to dataset data adapter. I am consistently told off
to only pick a small number of records for speed sake so I have come up with
this strategy to allow user to move forward one record at a time. I have a
similar sql for moving back one record at a time.

Thanks

Regards

"William Vaughn" <billvaNoSPAM@betav.com> wrote in message
news:FF3A40EB-F5DB-4643-B6CA-B2A661CF4854@microsoft.com...
> This query requires that the entire table be ordered before the ordinal is
> returned. I would look at the query plan in SSMS to see what kind of plan
> is being generated. I would also make sure that there are supporting
> indexes on the ID column. Fill is not the best choice here as you don't
> need to return a rowset but an ordinal. For this reason, I would use the
> Command.ExecuteScalar. This returns a single value (as an object).
>
> --
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205 (Pacific time)
> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
> ____________________________________________________________________________________________
> "John" <John@nospam.infovis.co.uk> wrote in message
> news:OwLNIG0eIHA.5984@TK2MSFTNGP06.phx.gbl...
>> Hi
>>
>> I am using a strongly typed dataset created by vs 2008. I have added a
>> query to select next record to the data adapter as below;
>>
>> SELECT TOP 1 <field list>
>> FROM MyTable
>> WHERE (ID > ?)
>> ORDER BY ID
>>
>> ? is replaced by the ID of the current record.
>>
>> My problem is when I fill using this query there is a noticeable about
>> half a second delay before data is retrieved. Is there any way to improve
>> the performance of this query?
>>
>> Thanks
>>
>> Regards
>>
>>
>



Re: ado.net data access performance by Mr

Mr
Sat Mar 01 14:59:14 CST 2008


"Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
news:uzhywi9eIHA.288@TK2MSFTNGP02.phx.gbl...
> Ahum :-(
>
> after rereading i am not so sure annymore about this
>
> "> I know for a fact that the TS is using ACCESS
>
>
> But okay you got the point i hope :-)
>

I don't know man. Maybe, you need to take a Bromo-Seltzer, drink a glass of
milk, eat a cookie, and settle down here. It's not that serious.


Re: ado.net data access performance by Mr

Mr
Sat Mar 01 15:14:06 CST 2008


"John" <John@nospam.infovis.co.uk> wrote in message
news:uOD3D99eIHA.1168@TK2MSFTNGP02.phx.gbl...
> Hi Bill
>
> I have skipped all the fields as there were too many to list. This is the
> sql which I have added to dataset data adapter. I am consistently told off
> to only pick a small number of records for speed sake so I have come up
> with this strategy to allow user to move forward one record at a time. I
> have a similar sql for moving back one record at a time.
>

Move forward one record at a time? If I was in your end-user base, there
would be a contract/hit put out on you to take you out in the parking lot.
:)


Re: ado.net data access performance by John

John
Sat Mar 01 15:28:42 CST 2008

They are used to access front end based apps which allow them to do that.
Hard to rid of old habits.

Regards

"Mr. Arnold" <MR. Arnold@Arnold.com> wrote in message
news:ufOkDF%23eIHA.1188@TK2MSFTNGP04.phx.gbl...
>
> "John" <John@nospam.infovis.co.uk> wrote in message
> news:uOD3D99eIHA.1168@TK2MSFTNGP02.phx.gbl...
>> Hi Bill
>>
>> I have skipped all the fields as there were too many to list. This is the
>> sql which I have added to dataset data adapter. I am consistently told
>> off to only pick a small number of records for speed sake so I have come
>> up with this strategy to allow user to move forward one record at a time.
>> I have a similar sql for moving back one record at a time.
>>
>
> Move forward one record at a time? If I was in your end-user base, there
> would be a contract/hit put out on you to take you out in the parking lot.
> :)



Re: ado.net data access performance by Mr

Mr
Sat Mar 01 16:02:54 CST 2008


"John" <John@nospam.infovis.co.uk> wrote in message
news:OyJw1M%23eIHA.5620@TK2MSFTNGP04.phx.gbl...
> They are used to access front end based apps which allow them to do that.
> Hard to rid of old habits.
>

You give them what they are use to working with in an application. That way,
they are happy, your boss is happy, and you'll be happy.


Re: ado.net data access performance by Cor

Cor
Sun Mar 02 13:43:21 CST 2008

Michel,

Will you tell us what is the overhead. Now your answer look to me the same
as insert 64Gb in your 32bits computer.

In my idea will a datareader not make it faster, my general expirience is
even oposite from that.

Cor


Re: ado.net data access performance by Cor

Cor
Sun Mar 02 13:45:23 CST 2008

John,

Is this in debugging or in release mode, while debugging a strongly typed
dataset is real slow.

Cor


Re: ado.net data access performance by Michel

Michel
Mon Mar 03 00:43:05 CST 2008

> Will you tell us what is the overhead.

All the datatable ,dataset and there constraints , validation that you
might not need
A datareader is connected , and is the equivalant of a old fashioned
Firehose cursor ( read only, forward only cursor )

So by using the datareader`s property`s you can skip the dataset , table
stuff if possible in your design and this gives you extra perfomance
and is especially handy for retrieving small blocks of data ,, or in
projects were you process large amounts of data ( as the data is not
preloaded as is common in disconnected architecture ) ofcourse this is
only suitable for readonly data


>
> In my idea will a datareader not make it faster, my general expirience is
> even oposite from that.
>

I wonder in wich special situation you encountered this, cause normally a
datareader should be superior in speed ( for obvious reassons ) however
without the strong typing etc etc

Michel



"Cor Ligthert[MVP]" <notmyfirstname@planet.nl> schreef in bericht
news:3223643E-D70F-47C5-AC8D-38A9EF0C5AF6@microsoft.com...
> Michel,
>
> Will you tell us what is the overhead. Now your answer look to me the same
> as insert 64Gb in your 32bits computer.
>
> In my idea will a datareader not make it faster, my general expirience is
> even oposite from that.
>
> Cor



Re: ado.net data access performance by Chris

Chris
Mon Mar 03 11:40:54 CST 2008

On Mar 1, 7:38 am, "John" <J...@nospam.infovis.co.uk> wrote:

> If I use datareader to replace "fill" my form controls, what method can I
> use to update the values back to db?
>

Since you are using VS2008, you might consider using LINQ to SQL. If
your queries are not extremely complex, you won't have to write any
SQL at all. You would just call the SubmitChanges method of the
DataContext class:

' DataContext takes a connection string.
Dim db As New DataContext("...\database.mdf") 'Use appropriate
connection string here

' Get a typed table to run queries.
Dim Orders As Table(Of Order) = db.GetTable(Of Order)()

' Query the database for the row to be updated.
Dim ordQuery = _
From ord In Orders _
Where ord.OrderID = 11000 _
Select ord

' Execute the query, and change the column values
' you want to change.
For Each ord As Order In ordQuery
ord.ShipName = "Mariner"
ord.ShipVia = 2
' Insert any additional changes to column values.
Next

' Submit the changes to the database.
db.SubmitChanges()


Of course you would change the code to suit your needs but with this
example, you would have to create an Order class and set up the
mapping to the database, but that is a one time setup. Linq makes the
code much more readable. I can't say if this will solve your
performance hiccup though. Using LINQ does not guarantee high
performance and, indeed, if you don't construct your LINQ queries
properly, you could degrade performance. but often, readability and
maintainability are preferred over a minute performance degradation.
Your mileage may vary, of course.

See this for more information:

http://msdn2.microsoft.com/en-us/library/bb399408.aspx

Chris

Re: ado.net data access performance by William

William
Mon Mar 03 11:41:21 CST 2008

The DataReader provides only the pipe, not the bucket. That is, it's just a
stream of data that must often be stored locally. Some developers think they
can out-write the coders at MS who implemented the DataTable Load method to
suck the data out of the DataReader--most fail in the attempt. Others use
the DataReader to bring a mountain of rows to the client to extract the
gold. The best solution in this case is to setup a ore processor at the
quarry--not in Denver 100 miles away only to ship it back. I recommend doing
this processing on the client using TSQL if possible or CLR procedures if
not. THIS is invariably faster.

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
"Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
news:eVnD3$RfIHA.1132@TK2MSFTNGP06.phx.gbl...
>> Will you tell us what is the overhead.
>
> All the datatable ,dataset and there constraints , validation that you
> might not need
> A datareader is connected , and is the equivalant of a old fashioned
> Firehose cursor ( read only, forward only cursor )
>
> So by using the datareader`s property`s you can skip the dataset , table
> stuff if possible in your design and this gives you extra perfomance
> and is especially handy for retrieving small blocks of data ,, or in
> projects were you process large amounts of data ( as the data is not
> preloaded as is common in disconnected architecture ) ofcourse this is
> only suitable for readonly data
>
>
>>
>> In my idea will a datareader not make it faster, my general expirience is
>> even oposite from that.
>>
>
> I wonder in wich special situation you encountered this, cause normally a
> datareader should be superior in speed ( for obvious reassons ) however
> without the strong typing etc etc
>
> Michel
>
>
>
> "Cor Ligthert[MVP]" <notmyfirstname@planet.nl> schreef in bericht
> news:3223643E-D70F-47C5-AC8D-38A9EF0C5AF6@microsoft.com...
>> Michel,
>>
>> Will you tell us what is the overhead. Now your answer look to me the
>> same as insert 64Gb in your 32bits computer.
>>
>> In my idea will a datareader not make it faster, my general expirience is
>> even oposite from that.
>>
>> Cor
>
>


Re: ado.net data access performance by Michel

Michel
Mon Mar 03 13:16:04 CST 2008

Huh ? Bill did you made a typo :-|

Shouldn`t this be

>I recommend doing
> this processing on the sever using TSQL if possible or CLR procedures if
> not. THIS is invariably faster.

Or am i completely missing something ? :-(


Michel





"William Vaughn" <billvaNoSPAM@betav.com> schreef in bericht
news:56F13648-9F2A-4D4D-9B4A-0E2324ABE507@microsoft.com...
> The DataReader provides only the pipe, not the bucket. That is, it's just
> a stream of data that must often be stored locally. Some developers think
> they can out-write the coders at MS who implemented the DataTable Load
> method to suck the data out of the DataReader--most fail in the attempt.
> Others use the DataReader to bring a mountain of rows to the client to
> extract the gold. The best solution in this case is to setup a ore
> processor at the quarry--not in Denver 100 miles away only to ship it
> back. I recommend doing this processing on the client using TSQL if
> possible or CLR procedures if not. THIS is invariably faster.
>
> --
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205 (Pacific time)
> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
> ____________________________________________________________________________________________
> "Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
> news:eVnD3$RfIHA.1132@TK2MSFTNGP06.phx.gbl...
>>> Will you tell us what is the overhead.
>>
>> All the datatable ,dataset and there constraints , validation that you
>> might not need
>> A datareader is connected , and is the equivalant of a old fashioned
>> Firehose cursor ( read only, forward only cursor )
>>
>> So by using the datareader`s property`s you can skip the dataset , table
>> stuff if possible in your design and this gives you extra perfomance
>> and is especially handy for retrieving small blocks of data ,, or in
>> projects were you process large amounts of data ( as the data is not
>> preloaded as is common in disconnected architecture ) ofcourse this is
>> only suitable for readonly data
>>
>>
>>>
>>> In my idea will a datareader not make it faster, my general expirience
>>> is even oposite from that.
>>>
>>
>> I wonder in wich special situation you encountered this, cause normally
>> a datareader should be superior in speed ( for obvious reassons )
>> however without the strong typing etc etc
>>
>> Michel
>>
>>
>>
>> "Cor Ligthert[MVP]" <notmyfirstname@planet.nl> schreef in bericht
>> news:3223643E-D70F-47C5-AC8D-38A9EF0C5AF6@microsoft.com...
>>> Michel,
>>>
>>> Will you tell us what is the overhead. Now your answer look to me the
>>> same as insert 64Gb in your 32bits computer.
>>>
>>> In my idea will a datareader not make it faster, my general expirience
>>> is even oposite from that.
>>>
>>> Cor
>>
>>
>



Re: ado.net data access performance by William

William
Mon Mar 03 13:33:32 CST 2008

Yes, of course. My migraine is getting to me.
Thanks

--
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________
"Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
news:%23cLbyLWfIHA.1132@TK2MSFTNGP06.phx.gbl...
> Huh ? Bill did you made a typo :-|
>
> Shouldn`t this be
>
> >I recommend doing
>> this processing on the sever using TSQL if possible or CLR procedures if
>> not. THIS is invariably faster.
>
> Or am i completely missing something ? :-(
>
>
> Michel
>
>
>
>
>
> "William Vaughn" <billvaNoSPAM@betav.com> schreef in bericht
> news:56F13648-9F2A-4D4D-9B4A-0E2324ABE507@microsoft.com...
>> The DataReader provides only the pipe, not the bucket. That is, it's just
>> a stream of data that must often be stored locally. Some developers think
>> they can out-write the coders at MS who implemented the DataTable Load
>> method to suck the data out of the DataReader--most fail in the attempt.
>> Others use the DataReader to bring a mountain of rows to the client to
>> extract the gold. The best solution in this case is to setup a ore
>> processor at the quarry--not in Denver 100 miles away only to ship it
>> back. I recommend doing this processing on the client using TSQL if
>> possible or CLR procedures if not. THIS is invariably faster.
>>
>> --
>> __________________________________________________________________________
>> William R. Vaughn
>> President and Founder Beta V Corporation
>> Author, Mentor, Dad, Grandpa
>> Microsoft MVP
>> (425) 556-9205 (Pacific time)
>> Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
>> ____________________________________________________________________________________________
>> "Michel Posseth [MCP]" <MSDN@posseth.com> wrote in message
>> news:eVnD3$RfIHA.1132@TK2MSFTNGP06.phx.gbl...
>>>> Will you tell us what is the overhead.
>>>
>>> All the datatable ,dataset and there constraints , validation that you
>>> might not need
>>> A datareader is connected , and is the equivalant of a old fashioned
>>> Firehose cursor ( read only, forward only cursor )
>>>
>>> So by using the datareader`s property`s you can skip the dataset , table
>>> stuff if possible in your design and this gives you extra perfomance
>>> and is especially handy for retrieving small blocks of data ,, or in
>>> projects were you process large amounts of data ( as the data is not
>>> preloaded as is common in disconnected architecture ) ofcourse this is
>>> only suitable for readonly data
>>>
>>>
>>>>
>>>> In my idea will a datareader not make it faster, my general expirience
>>>> is even oposite from that.
>>>>
>>>
>>> I wonder in wich special situation you encountered this, cause normally
>>> a datareader should be superior in speed ( for obvious reassons )
>>> however without the strong typing etc etc
>>>
>>> Michel
>>>
>>>
>>>
>>> "Cor Ligthert[MVP]" <notmyfirstname@planet.nl> schreef in bericht
>>> news:3223643E-D70F-47C5-AC8D-38A9EF0C5AF6@microsoft.com...
>>>> Michel,
>>>>
>>>> Will you tell us what is the overhead. Now your answer look to me the
>>>> same as insert 64Gb in your 32bits computer.
>>>>
>>>> In my idea will a datareader not make it faster, my general expirience
>>>> is even oposite from that.
>>>>
>>>> Cor
>>>
>>>
>>
>
>


Re: ado.net data access performance by Cor

Cor
Mon Mar 03 23:01:51 CST 2008

Michel,

Yes but what you write the case here

I used the datareader in past to get small amounts of which exist is more
than two pieces. Now I use more and more the executescalar and connect the
two pieces to a string with an # as seperator and split them after
receiving.

Ever tried? In my idea it is very effective.

(I don't have batch processing here, in that case I would have used the
datareader, by instance when I had to process a bunch of invoices for a
energie company).

Cor