By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,164 Members | 1,018 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,164 IT Pros & Developers. It's quick & easy.

Efficiency of SQL UPDATE vs Recordset .edit/.update

P: n/a
Hi

Using A2003 on XP

I am wondering from the MVP's and others, what is the most efficient way (in
terms of time to process) of updating data in a table, using the
docmd.RunSQL or Recordset 'Edit' and 'Update'?

eg: (if you need it)

1.--------------------------

mysql = "Update [mytable] SET [SomeField] = [somevalue];"
docmd.RunSQL mysql
2.-----------------------

set myrecordset = mydb.OpenRecordset([tablename / sql])
myrecordset.edit
myrecodset.fields("myfield") = [somevalue]
myrecordset.update
TIA
Michelle


Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Wed, 4 Feb 2004 14:30:44 +1000, "-Michelle-" <mi********@yahoo.com> wrote:
Hi

Using A2003 on XP

I am wondering from the MVP's and others, what is the most efficient way (in
terms of time to process) of updating data in a table, using the
docmd.RunSQL or Recordset 'Edit' and 'Update'?

eg: (if you need it)

1.--------------------------

mysql = "Update [mytable] SET [SomeField] = [somevalue];"
docmd.RunSQL mysql
2.-----------------------

set myrecordset = mydb.OpenRecordset([tablename / sql])
myrecordset.edit
myrecodset.fields("myfield") = [somevalue]
myrecordset.update
TIA
Michelle


Well, whichever way is faster, SQL Update vs Recordset, DoCnd,RunSQL is a very
inefficient way to execute a SQL command, and there are other good reasons not
to use it from code. It's better to use the .Execute method of a DAO Detabase
or QueryDef object, or of an ADO Connection or Command object.

With regard to whether the SQL update or the recordset is more efficent, it
depends an awful lot on context, but the SQL is generally better. For one
thing, before you can update a record using a recordset, you must find it. If
this is done with a Where clause in a SELECT statement, you are no making
several calls through the database layer instead of just 1. If you do it with
FindFirst, you are searching through the rows in a recordset with no
optimization at all.

Another factor is that any query, whether it is a SELECT or an UPDATE must
first be compiled before it is run. If you execute a SQL statement
repeatedly, compiling it each time, this will be much slower than if you
compile it once, then execute it multiple times. If you do this with a saved
query that takes parameters, the query will be compiled the first time you run
it, and the compiled state will be saved with the query and reused next time.
If you use a temporary querydef in code and reuse the same querydef multiple
times, it will be compiled the first time you execute it, and the compiled
state will be preserved until the querydef variable is released.

Here's an example using a DAO temporary querydef from code.

Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Dim prmFooID As DAO.Parameter
Dim prmFooName As DAO.Parameter

Set dbs = CurrentDB()
Set qdf = dbs.CreateQuerydef("")
qdf.SQL = "UPDATE tblFoo SET tblFoo.FooName=prmFooName " & _
"WHERE tblFoo.FooID=prmFooID"
Set prmFooID = qdf!prmFooID
Set prmFooName = qdf!prmFooName

prmFooID.Value=1: prmFooName.Value="ABC"
qdf.Execute dbFailOnError ' Takes a brief time to compile before running.
prmFooID.Value=2: prmFooName.Value="DEF"
qdf.Execute dbFailOnError ' Still comiled from previous Execute.
prmFooID.Value=3: prmFooName.Value="GHI"
qdf.Execute dbFailOnError ' Still compiled.

' DAO can be unhappy if we don't clean up our objects in reverse order of
' dependency.
Set prmFooID = Nothing: Set prmFooName = Nothing
Set qdf=Nothing
Set dbs = Nothing
Nov 12 '05 #2

P: n/a
-Michelle- wrote:
Hi

Using A2003 on XP

I am wondering from the MVP's and others, what is the most efficient way (in
terms of time to process) of updating data in a table, using the
docmd.RunSQL or Recordset 'Edit' and 'Update'?


I prefer Currentdb.Execute strSQL. RunSQL is fine too.

I sometimes will use Add/Update when I want to do an insert using the Insert
Into Table (fields....) Values (.....) command because of all the quote and
comma permutations required to write the SQL string that can be parsed by
Access....a PITA to write....and if the data has single or double quotes it gets
to be even more frustrating whileusing a recordset is easy to write and requires
little or no debugging.

Nov 12 '05 #3

P: n/a
Thank you both for replying. Again, this newsgroup has provided an
invaluable service with information coming from real people in an
understandable format, not just from a reference book.

I couldn't live without the newsgroups.

Thanks
Michelle
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.