Re: Effects on RST in Calling Proc

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.
.