Discussion on:
View:
Show:
There was nothing in the article about command object capabilities that a recordset couldn't do. It would be helpful if a more direct comparison was done, with guidelines for when to use a command object over a recordset. Performance and coding flexibility ratings would also be helpful.
actually they want to said that you can do the same thing with the recordset and command object but if you want to update o delete use command because is more faster.
Is the execute method any faster or slower than using the command object for INSERT/UPDATE/DELETE
David -
the two main points this article is trying to make (or should be making) are: 1) speed and 2) stored procedures.
if you are working with small amounts of data and capicity/speed issues are not a concern, then the article is not that relevant.
however, there is no doubt that stored procedures offer a benefit in speed, flexability and structured code (seperating data access from presentation code).
-grant russel
the two main points this article is trying to make (or should be making) are: 1) speed and 2) stored procedures.
if you are working with small amounts of data and capicity/speed issues are not a concern, then the article is not that relevant.
however, there is no doubt that stored procedures offer a benefit in speed, flexability and structured code (seperating data access from presentation code).
-grant russel
I personally think this debate about Command Object versus Recordset Objects is academic and misleading. They each have their own place and some things can only be done with the Command Object and some only with the Recordset object.
If you are using a recordset object you must be dillgent of its default behaviour. For example, the default cachesize parameter is one record. This means that every movenext will result in a round trip across the network (read: slow). Setting the cachesize to a larger figure for a read-only, forward-only recordset can yield a significant performance improvement.
Similarly setting a recordset into batch update mode can out perform single insert/update SQL commands into a command object or connection.execute
If you do not wnat to take the time to consider where and how updates are occuring then the defaults are a good safe setting. If you need speed then then playing with these settings and with the other objects can yeild rich rewards.
- Gary
If you are using a recordset object you must be dillgent of its default behaviour. For example, the default cachesize parameter is one record. This means that every movenext will result in a round trip across the network (read: slow). Setting the cachesize to a larger figure for a read-only, forward-only recordset can yield a significant performance improvement.
Similarly setting a recordset into batch update mode can out perform single insert/update SQL commands into a command object or connection.execute
If you do not wnat to take the time to consider where and how updates are occuring then the defaults are a good safe setting. If you need speed then then playing with these settings and with the other objects can yeild rich rewards.
- Gary
You fell short by not displaying how to use the command object to run stored procedures/SQL statements with parameters.
such as:
cmd.ActiveConnection = CurrentProject.Connection
cmd.CommandText = "qryRepCreditNoBalanceReport"
cmd.CommandType = adCmdStoredProc
Set prmBillingPeriod = cmd.CreateParameter("prmBillingPeriod", adDate, adParamInput, , lastBillingPeriod)
cmd.Parameters.Append prmBillingPeriod
Set prmPaymentDate = cmd.CreateParameter("prmPaymentDate", adDate, adParamInput, , asOfDate)
cmd.Parameters.Append prmPaymentDate
cmd.execute
such as:
cmd.ActiveConnection = CurrentProject.Connection
cmd.CommandText = "qryRepCreditNoBalanceReport"
cmd.CommandType = adCmdStoredProc
Set prmBillingPeriod = cmd.CreateParameter("prmBillingPeriod", adDate, adParamInput, , lastBillingPeriod)
cmd.Parameters.Append prmBillingPeriod
Set prmPaymentDate = cmd.CreateParameter("prmPaymentDate", adDate, adParamInput, , asOfDate)
cmd.Parameters.Append prmPaymentDate
cmd.execute
Hi,
I don't know, why I should use ADO, when I can use
SqlConnection, and SqlCommand easily, which is more
faster?
Thanks
I don't know, why I should use ADO, when I can use
SqlConnection, and SqlCommand easily, which is more
faster?
Thanks
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
