How does Update differ from UpdateBatch?

[jal]

As a newbie to recordsets, unsure of what I was doing, I have been using only Update, not UpdateBatch. Typically I would read in a textfile line by line, adding each line as a new record to the recordset and then, when all the records were added, I would call recSet.Update.

As far I can see, then, recSet.Update has been updating entire batches for me. I never used updateBatch and therefore I don't see the need for it.

So what's the difference?

Also, is there a performance advantage to calling UpdateBatch?

 

[nIGHTmAYOR]

updatebatch is an ado feature that adds the functionality of replication to applications relying on ado in communicating with databases and since access has its own replication module mind you it is already a database than rather an application access isnt benefiting much of such a feature.

 

[jal]

updatebatch is an ado feature that adds the functionality of replication to applications relying on ado in communicating with databases and since access has its own replication module mind you it is already a database than rather an application access isnt benefiting much of such a feature.

Interesting. Thank you.

 

[LPurvis]

OK, my description on this would be quite a bit different.

UpdateBatch is a method of an ADO recordset - I agree.
It's purpose is to facilitate the largescale (batch) update of data entered into a recordset which is of a Batch Update lock type - typically implemented in a disconnected recordset.

Although Access doesn't support the binding of forms to such recordsets in a manner which permits the batch updates to operate, the recordset type itself as a part of ADO is very important and has uses within Access - and very much so outside (for example in ASP work etc).
For a local example you could open an ADO recordset in Access in batch mode, disconnect it. Then use the contents to fill a form with data from a record as required - updating the recordset in memory as you navigate - but pending the decision to write back all records until an explicit BatchUpdate command.

That the ADO recordset ReSync command is related to UpdateBatch merely speaks to the option to occasionally refresh the the data in the recordset. This could then raise certain conflict issues which, it can be argued, have conceptual analogies to Replication conflicts - but doesn't speak to that kind of functionality directly and isn't what the functionality is generally about.

Cheers.

 

[datAdrenaline]

Hello Jal ...

Adding to Leigh's excellent description, it may be appropriate to add that in the scenario you describe, ADO is AUTOMATICALLY issueing the Update method as you navigate away from the new record, so you are not updating in a batch fashion.

Here is a clip from the ADO help on the Update method ...

>> If you move from the record you are adding or editing before calling the Update method, ADO will automatically call Update to save the changes. <<

So your call to the Update method is mere saving the changes of the last record you are adding.

....

Hope the helps!

 

[LPurvis]

I didn't read your actual scenario - so sorry for not addressing your observed behaviour.

However to be clear - you can only see the mentioned functionality for UpdateBatch on a recordset which has been opened with a LockEdits property of adLockBatchOptimistic. If you don't - then it behaves as an Update command.
Conversely - Update does *not* work as a synonym for UpdateBatch on a BatchOptimistic recordset. Indeed - it will do precisely nothing. Nor will the navigation referenced by Brent in his post. Batch mode recordsets are specifically for batch updating.

Cheers.

 

[jal]

Hello Jal ...

Adding to Leigh's excellent description, it may be appropriate to add that in the scenario you describe, ADO is AUTOMATICALLY issueing the Update method as you navigate away from the new record, so you are not updating in a batch fashion.

Here is a clip from the ADO help on the Update method ...

>> If you move from the record you are adding or editing before calling the Update method, ADO will automatically call Update to save the changes. <<

So your call to the Update method is mere saving the changes of the last record you are adding.

....

Hope the helps!

Yes it helps one heck of a lot. As the previous commentary was a bit over my head, your statement sheds the most light on the matter so far.

 

[jal]

I didn't read your actual scenario - so sorry for not addressing your observed behaviour.

However to be clear - you can only see the mentioned functionality for UpdateBatch on a recordset which has been opened with a LockEdits property of adLockBatchOptimistic. If you don't - then it behaves as an Update command.
Conversely - Update does *not* work as a synonym for UpdateBatch on a BatchOptimistic recordset. Indeed - it will do precisely nothing. Nor will the navigation referenced by Brent in his post. Batch mode recordsets are specifically for batch updating.

Cheers.

Thanks for completing the picture.

 

[datAdrenaline]

Jal ...

>> Yes it helps one heck of a lot. <<

Cool. Always, glad to help out!