ADO performance question 
Author Message
 ADO performance question

Hi there

I have a question about ADO and performance. Should you always access a
datasource through ADO using all of the connection,  command, recordset
objects, or are there performance gains in using the command object alone,
and then providing a connection string as parameter etc ?

Best regards

Mowgli



Sat, 03 Nov 2001 03:00:00 GMT  
 ADO performance question
You'll take a huge performance hit if you pass a connection string to your
Recordset.Open method instead of a Connection object.  If I'm creating
multiple recordsets/connections/command objects, I usually open a Connection
object then pass that object in the Recordset/Connection/Command.Open
method.

--
Jon Pope
Coherent Technologies, Inc.
(Remove .NoSpam Before Replying)


Quote:
> Hi there

> I have a question about ADO and performance. Should you always access a
> datasource through ADO using all of the connection,  command, recordset
> objects, or are there performance gains in using the command object alone,
> and then providing a connection string as parameter etc ?

> Best regards

> Mowgli



Sat, 03 Nov 2001 03:00:00 GMT  
 ADO performance question
Hi Mowgli -

My own experience so far with ADO has shown that it is best to use the
primary ADO objects as follows -

Connections -

Use the connection execute method with a SQL statement to perform any
updates to records. Update, Delete, Insert, etc, can all be run
directly on records in a database. This is by far the quickest and
least expensive in memory option.

cn.Execute "Delete * From Employees"

Commands -

Only use a command if you have parameters to send to a stored
procedure. Everything else a command can do can be done with a
connection and/or a recordset. Avoid using a command to set a recordset.

Recordsets -

Slowest of all objects - if possible replace what you are going to do
with an SQL statement and a connection.Execute command. Otherwise if
you have to use one, set the CursorLocation, CursorType and Lock
properties to the best combination for speed. ie Read Only, Forward
Scrolling.

I have found that it is a must to avoid using all the objects together.
Never open a connection, then a command, and then set the recordset to
the commands resultset. Apps just die a death.

ADO has its Object Model de-emphasised to enable rapid instantiation of
the individual objects. Although not yet complete, I reckon it is a
huge improvement on DAO/RDO.

Regards

Stuart



Quote:
> Hi there

> I have a question about ADO and performance. Should you always access
a
> datasource through ADO using all of the connection,  command,
recordset
> objects, or are there performance gains in using the command object
alone,
> and then providing a connection string as parameter etc ?

> Best regards

> Mowgli

--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


Sun, 04 Nov 2001 03:00:00 GMT  
 ADO performance question

Quote:

> My own experience so far with ADO has shown that it is best to use the
> primary ADO objects as follows -

Hi.

When I use a ADO Data control and/or a ADO Data Grid it always loads all the
recordset into the Client memory when it opens it. Therefore if I just need
to scroll a talble with about 15000/20000 records I have to wait about 50-60
seconds before the form appears.
If I use ODBCDirect+DataControl+DBGrid32 the perfomances are hugely better.
Any suggestion?

Thank you.

Francesco



Mon, 12 Nov 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. ADO performance question

2. ADO Performance Question

3. ADO Performance question

4. ADO's Performance vs DAO's Performance

5. ado performance - ms-access vs odbc

6. ADO Performance

7. Performance problems with shaped record sets and collections - VB6, ADO

8. How to improve ADO performance

9. Performance issue - Access 2000 using VB6 and ADO 2.1 with SQL

10. ADO: Performance Testing vs. DAO

11. Improving ADO performances against SQL Server?

12. ADO "AddNew" Performance Issue

 

 
Powered by phpBB® Forum Software