.BOF and .EOF are lying!

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?

Can you post more details, such as sample data, the form's recordsource, the
code you're using, etc.? Kinda hard to suggest anything when we really don't
know what your form is doing.

--

Ken Snell
MS ACCESS MVP

"Laurel" wrote in message
...
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?

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" wrote in message
...
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?

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

I'm not using a record clone.

"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
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" wrote in message
...
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?

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.

Ok, I've never seen that.

I'm not using a record clone.

What /ARE/ you doing?

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.

(david)



"Laurel" wrote in message
...
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
...
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" wrote in message
...
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?

See below

"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
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" wrote in message
...
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
...
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" wrote in message
...
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?

Me.Recordset.EOF

ahh. I've never used me.recordset. I hope .recordcount
works, because I don't know any other solution.

(david)



"Laurel" wrote in message
...
See below

"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
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" wrote in message
...
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
...
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" wrote in message
...
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?

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" wrote in message
...
See below

"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
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" wrote in message
...
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
...
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" wrote in message
...
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?

"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]" wrote in message
...
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" wrote in message
...
See below

"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
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" wrote in message
...
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
...
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" wrote in message
...
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?

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

"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]" wrote in message
...
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" wrote in message
...
See below

"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
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" wrote in message
...
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
...
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" wrote in message
...
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?