Re: .BOF and .EOF are lying!
- From: "Ken Snell [MVP]" <kthsneisllis9@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 18 Aug 2005 19:54:56 -0400
I'm not sure if your post was meant for me or for Laurel.
Nonetheless, the information is consistent with what I am suggesting... that
the "failure" is not a "failure" but rather a misplaced expectation that the
BOF and EOF properties would have a specific value at a certain time, based
on what is being done in the code/recordset. And, as no specific example of
the circumstances surrounding the "failure" have been posted, it's difficult
to postulate the reason for the seeming "failure".
If you're reading my use of the term "put...at a different place" to mean
only a physical "place" then I apologize for the misunderstanding that it
seems to have caused.
--
Ken Snell
<MS ACCESS MVP>
"david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
news:OxLIK3EpFHA.1412@xxxxxxxxxxxxxxxxxxxxxxx
>
> "An OpenRecordset method internally invokes a MoveFirst
> "method. Therefore, using an OpenRecordset method on an
> "empty set of records sets the BOF and EOF properties to
> "True.
>
> AFAIK, nothing that doesn't invoke a Move method sets
> the BOF or EOF properties.
>
> For example
>
> "Any Delete method, even if it removes the only remaining
> "record from a Recordset, won't change the setting of the
> "BOF or EOF property.
>
> You might read that
>
> "When you use Requery, the first record in the Recordset
> "becomes the current record.
>
> and
>
> "If both the BOF and EOF property settings of the Recordset
> "object are True after you use the Requery method, the query
> "didn't return any records and the Recordset contains no data.
>
> But if you read more carefully, you will notice that in
> some cases "the Recordset is re-created from scratch.",
> and in other cases "the Recordset is re-populated"
>
>
>> the recordset's data (by a requery?) and then the "failure" occurs. Most
>> likely, the "failure" is because the refresh/requery has put you at a
>> different place in the recordset than where you thought you were?
>
> No, the "failure" is because the BOF and EOF properties are
> not set at all by some actions.
>
> (david)
>
>
> "Ken Snell [MVP]" <kthsneisllis9@xxxxxxxxxxxxxxxxxx> wrote in message
> news:e$8ACG6oFHA.2916@xxxxxxxxxxxxxxxxxxxxxxx
>> You haven't shown us the specific circumstance when the BOF and EOF
>> properties "fail", but from your posts it appears that you are refreshing
>> the recordset's data (by a requery?) and then the "failure" occurs. Most
>> likely, the "failure" is because the refresh/requery has put you at a
>> different place in the recordset than where you thought you were?
>>
>> I use BOF and EOF regularly with recordsets -- both those opened in code
>> and those for forms' recordset or recordsetclone. I have not have any
>> difficulty with either.
>>
>> If you can post a specific example of what you are seeing (code and
>> example data), I'm sure we can assist you.
>>
>> By the way, although the RecordCount of the form's recordset often can
>> mislead you because it doesn't have the "correct" count unless you do a
>> .MoveLast, the form's RecordsetClone.RecordCount property has always had
>> a correct count for me without having to use .MoveLast.
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>> --
>>
>> Ken Snell
>> <MS ACCESS MVP>
>>
>>
>>
>> "Laurel" <FakeMail@xxxxxxxxxxx> wrote in message
>> news:uRoQsM4oFHA.2792@xxxxxxxxxxxxxxxxxxxxxxx
>>> See below
>>>
>>> "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
>>> news:ufE6TO3oFHA.3256@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> you can't trust .recordcount until you've done a .movelast.
>>>>
>>>> No, but I've always had > 0
>>>>
>>>>> Before moving to the last record, sometimes the record count is 0.
>>>
>>> Well, you may be on to something. I went back to a form where I thought
>>> I was getting 0 instead of the full count, but it turns out it was 1.
>>> So I'll give .RecordCount = 0 a try.
>>>
>>>>
>>>> Ok, I've never seen that.
>>>>
>>>>> I'm not using a record clone.
>>>>
>>>> What /ARE/ you doing?
>>>
>>>
>>> For forms
>>> Me.Recordset.RecordCount
>>> or Me.Recordset.Bof, .EOF
>>>
>>> or, sometimes
>>> Dim lrst_Me As Recordset
>>> Set lrst_Me = Me.Recordset
>>>
>>> Very often I'm dealing with a recordset created this way:
>>> Set irst_ClassPeriods = CurrentDb.OpenRecordset(ls_sql)
>>>
>>>
>>>
>>>>
>>>>>>> retrieval arguments? If I retrieve the data in the form and rows,
>>>>>>> and then I change the values that are used as arguments
>>>>
>>>> What are you testing for BOF and EOF? Forms don't have a BOF
>>>> or EOF parameter. Please show your code.
>>>
>>> Me.Recordset.EOF
>>>
>>>>
>>>> (david)
>>>>
>>>>
>>>>
>>>> "Laurel" <FakeMail@xxxxxxxxxxx> wrote in message
>>>> news:OA88ms1oFHA.3036@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>I got into testing .bof and .eof because I learned that you can't trust
>>>>>.recordcount until you've done a .movelast. (And I have confirmed this
>>>>>myself.... several times... Before moving to the last record, sometimes
>>>>>the record count is 0. Sometimes it is the unfiltered count, etc.)
>>>>>Anyway, testing for .eof and .bof was a way of avoiding an error when
>>>>>.movelast was attempted on an empty recordset.
>>>>>
>>>>> So here we are coming around the circle again....
>>>>>
>>>>>
>>>>> "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
>>>>> news:uFNp6bvoFHA.2580@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> Use .recordcount > 0 to check if the recordset is empty.
>>>>>> Then use move or find if you want to position at a record.
>>>>>>
>>>>>> Remember that by definition .RecordsetClone is a recordset
>>>>>> with different record pointers than those used by the form.
>>>>>>
>>>>>> Ignore whatever the help files say about .bof and .eof
>>>>>> for recordset clones: The help was never correct.
>>>>>>
>>>>>> (david)
>>>>>>
>>>>>> "Laurel" <FakeMail@xxxxxxxxxxx> wrote in message
>>>>>> news:OISvtztoFHA.2580@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>> Are there steps one should take before requerying a form with
>>>>>>> different retrieval arguments? If I reetrieve the data in the form
>>>>>>> and there are rows, and then I change the values that are used as
>>>>>>> arguments to something that would return no rows .EOF and .BOF are
>>>>>>> both false.
>>>>>>>
>>>>>>> If the arguemtns that would return no rows are used first, .bof and
>>>>>>> .eof are true as one would expect.
>>>>>>>
>>>>>>> Any suggestions?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
.
- Follow-Ups:
- Re: .BOF and .EOF are lying!
- From: david epsom dot com dot au
- Re: .BOF and .EOF are lying!
- References:
- .BOF and .EOF are lying!
- From: Laurel
- Re: .BOF and .EOF are lying!
- From: david epsom dot com dot au
- Re: .BOF and .EOF are lying!
- From: Laurel
- Re: .BOF and .EOF are lying!
- From: david epsom dot com dot au
- Re: .BOF and .EOF are lying!
- From: Laurel
- Re: .BOF and .EOF are lying!
- From: Ken Snell [MVP]
- Re: .BOF and .EOF are lying!
- From: david epsom dot com dot au
- .BOF and .EOF are lying!
- Prev by Date: Re: .BOF and .EOF are lying!
- Next by Date: Re: Newbie Help on Football/Soccer Database
- Previous by thread: Re: .BOF and .EOF are lying!
- Next by thread: Re: .BOF and .EOF are lying!
- Index(es):
Relevant Pages
|