DoCmd.GoToRecord vs. Recordset.Move

[BruceM via AccessMonster.com]

A recent question in this forum led me to wondering whether there are
advantages or disadvantages one way or the other to using DoCmd.GoToRecord
acFirst or Me.Recordset.MoveFirst (same question about moving to the last,
previous, next, or new) for custom navigation buttons or other code. I often
use an adaptation of Lebans' NavButtons subform, but I use the syntax Me.
Parent.Recordset.MoveFirst. Somewhere along the way I took to using the
Recordset syntax, but now I wonder about it.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/200909/1

[Banana]

I had basically asked similar question, and made a sample to highlight
the differences.

(watch out for broken link from wraparound)

http://www.utteraccess.com/forums/showflat.php?Cat=&Board=84&Number=1847582&Zf=&Zw=&Zg=0&Zl=a&Main=1847582&Search=true&where=&Zu=123446&Zd=l&Zn=&Zt=18&Zs=&Zy=#Post1847582&Zp=

HTH.

[Klatuu]

Personnaly, I use the Recordset object's methods rather than go external to a
Docmd object.

I have not done any testing or evaluation that supports that choice, but it
seems more natural to me.
--
Dave Hargis, Microsoft Access MVP

[Jack Leach]

If the post in your reference is the one I'm thinking of, I advised the op to
use the DoCmd methods for navigation, which is my personal preference. After
reading the UtterAccess post that Banana provided, and and now wondering if I
was in line with my earlier recommendation...

--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

[Banana]

FWIW, both methods work equally well.

The difference lies in what we are actually dealing. A good example is
when we want to manipulate subform's navigation from the main form, or
maybe from another form. Doing so with DoCmd would be more work than if
we simply used the recordset methods.

For that reason, I find myself preferring Recordset/RecordsetClone
property more frequently.

[Jack Leach]

Another testimony would be locating a record mid-recordset by using a Record
ID... I've always used the RecordsetClone, FindFirst and Bookmark method for
this, because the DoCmd equivelant is based of the record index rather the
the data in the ID field, which is generally far more readily available.

But then, for other's, DoCmd.GotoRecord, , acLast is a lot easier than using
a recordset IMO, unless of course you are navigating a subform from it's
parent (or anywhere else).

I had no idea this was such a debated subject until recently... always
learning
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)

[BruceM via AccessMonster.com]

Your post was the one I has in mind. In many cases I use an adaptation of
Lebans' navigation buttons subform for record navigation. I added arguments
so that the navigation text box shows specific infomation (e.g. 5 of 12 Open
Invoices, or New Invoice), and I use Me.Parent.Recordset.MoveNext syntax for
the individual navigation buttons. It has been working, and I am coming to
the conclusion that I may as well continue to use it unless a problem arises.
From what I have seen in this discussion and the UtterAccess thread there is
no compelling reason for me to change something that is working, but I would
come to the same conclusion if I was using DoCmd.

Jack Leach wrote:
>If the post in your reference is the one I'm thinking of, I advised the op to
>use the DoCmd methods for navigation, which is my personal preference. After
>reading the UtterAccess post that Banana provided, and and now wondering if I
>was in line with my earlier recommendation...
>

>> A recent question in this forum led me to wondering whether there are
>> advantages or disadvantages one way or the other to using DoCmd.GoToRecord

>[quoted text clipped - 3 lines]

>> Parent.Recordset.MoveFirst. Somewhere along the way I took to using the
>> Recordset syntax, but now I wonder about it.

--
Message posted via http://www.accessmonster.com