Re: Effects on RST in Calling Proc

Steve Jorgensen wrote: 
On Sun, 04 Sep 2005 13:49:10 -0500, "David W. Fenton"
<dXXXfenton@xxxxxxxxxxxxxxxx> wrote:


rkc <rkc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
news:zCBSe.54285$EX.9212@xxxxxxxxxxxxxxxxxxxx: 


David W. Fenton wrote:

rkc <rkc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
news:KcrSe.54251$EX.21809@xxxxxxxxxxxxxxxxxxxx:



David W. Fenton wrote:

My rule: Never depend on bookmarks for anything where you can
use actual data to do so. Use bookmarks only for circumstances
where you *can't* use data. 

What could possibly cause just the bookmark property to fail in a
recordset opened as a snapshot?


You're asking the wrong question. I don't know that there are any
such conditions that lead to failure, but I don't know that there
are not. What I do know is that navigating by PK will *never*
fail if the recordset itself remains valid.

Why use something that is a black box about which I know very
little when there's a guaranteed method that doesn't have any
blackbox aspects to it? 

I don't see why you view the FindFirst method as any less of a
blackbox. The bookmark property is available for the exact purpose
of flagging and returning to a specific record in a recordset.
Saying that you can do the same in a more round about way doesn't
make it mysterious or unreliable.

But we know that a bookmark is volatile data, while the primary key
is *not* volatile.

FindFirst is a method, whereas a bookmark is a form of data. I'm
advocating the use of reliable data for your navigation, and the
volatility of a bookmark makes me wary of using it except when it
can't possibly have been invalidated (i.e., immediately after a
Findfirst).

I am suspicious of any code that stores a bookmark value, as there
should always be a better method of getting back to the same record
using real data, rather than metadata about the recordset. 


A concrete reason to use FindFirst rather than a bookmark would be that a
bookmark depends on the fact that you are using the same recordset both times,
and it has not been requeried.  What happens later if a need has arisen to
requery the recordset between the time the position has been recorded and when
you need to return to it?

That said, bookmarks have the advantage of not depending on a particular
definition of a row identifier for a given recordset, and doesn't require
searching on a combination of values when the row identifier for a recordset
cannot be a single value.

I don't have one single policy on this dilemma, but decide case-by-case.

The op's question involved a recordset opened as a snapshot and no mention was made of a requery. I can't think of a safer senario in
which to use a bookmark.


.