RecordsetClone theory

[Guest]

Hi,

In the MS Accesguide "VB for App's" I read about finding a record in a table
by using Set rst => RecordsetClone => Findfirst => Bookmark => etc.
In the book it says that, with using the property RecordsetClone, a copy of
the recordset is made, you work in the copy, and at the end the changes in
the copy are put in the original recordset.

My question is: why is Access/VB not working DIRECTLY IN THE ORIGINAL
RECORDSET, but via the clone ?
I'm sure the must be a logical reason, but don't see it and can't find it
in the tutorial.

Can anyone please explain ?
Thank you in advance

 

[Dirk Goldgar]

Hi,

In the MS Accesguide "VB for App's" I read about finding a record in
a table by using Set rst => RecordsetClone => Findfirst => Bookmark
=> etc.
In the book it says that, with using the property RecordsetClone, a
copy of the recordset is made, you work in the copy, and at the end
the changes in the copy are put in the original recordset.

My question is: why is Access/VB not working DIRECTLY IN THE ORIGINAL
RECORDSET, but via the clone ?
I'm sure the must be a logical reason, but don't see it and can't
find it in the tutorial.

Can anyone please explain ?
Thank you in advance

Three reasons:

1. Until Access 2000, the form's recordset was not directly accessible.
The form had no (public) Recordset property, only the RecordsetClone
property.

2. Actions performed directly on the form's recordset (obtained via the
Recordset property) are reflected immediately on the form. That
includes navigation -- if you move in the form's recordset, the form's
currently displayed record changes. If you perform an AddNew on the
form's recordset, the form displays the "new record".

Sometimes, that's what you want. Other times it isn't. For example, if
you just want to position the form to a different record located by
FindFirst, it's perfectly okay to do this:

Me.Recordset.FindFirst "ID=" & lngIDtoFind

.... instead of this:

With Me.RecordsetClone
.FindFirst "ID=" & lngIDtoFind
If Not .NoMatch Then
Me.Bookmark = .Bookmark
End If
End With

On the other hand, if you want to look at some record in the form's
recordset *without changing the record displayed on the form*, then you
must use the RecordsetClone, because navigation in the form's
RecordsetClone is not reflected on the form.

3. Also, form events are not raised by any of the actions you may take
on the RecordsetClone. But actions performed on the form's Recordset,
because they are reflected on the form, may cause form events to fire.
This may or may not be desirable.

 

[BW]

I'm fairly new to the VBA side of things. Did you say that any changes
made to the recordset clone are then saved to the original forms recordset
automatically?

 

[Dirk Goldgar]

I'm fairly new to the VBA side of things. Did you say that any
changes made to the recordset clone are then saved to the original
forms recordset automatically?

I'm not sure what you mean. Both the form's recordset and the clone of
that recordset are linked to the same table or tables. Changes to the
records and fields in one will be reflected in the other, so data
changes made to the recordsetclone will be apparent on the form.
However, the form's recordset is linked to the form, so the current
record in the recordset is the current record on the form, and
navigation in the recordset also navigates the form. But the
recordsetclone is not linked directly to the form, so you can navigate
in the recordsetclone without affecting the form.

 

[Guest]

Hi Dirk,
Understanding WHY makes it easier for me to remember the programming code.
You helped me on that. Thank you very much !

Hi BW,
Dirk answered my question but I leave it up to you to conclude the thread,
in case you need to go on on this.

Greetings

 

[BW]

Dirk, You response clarified my question. I was misunderstanding
"RecordsetClone" to mean a static copy of the forms data.

Thanks
Brent