HasData property for a subform??

[Guest]

Hi,

I'm working with a subform on a main form, and was wondering if there is a
HasData property (or something similar) that I can use in the code to figure
out if the subform has any records or not. The subform is a bound form,
linked to the main form. I can use Count, but if there is another easier way,
I'd prefer that.

Thanks.

-Amit

PS. I tried using Me!sfrmcontrol.Form.HasData and it gave me a run-time
error (something like "property not supported")

 

[Guest]

Hi, Amit.

I'm working with a subform on a main form, and was wondering if there is a
HasData property (or something similar) that I can use in the code to figure
out if the subform has any records or not.

Only reports have the HasData Property, not forms. However, one may use the
form's Recordset Property to obtain the RecordCount for the form. If this
number is zero, then there are no records displayed.

If the subform is linked to the main form via a common field, then to
determine how many records the subform is displaying for the current record
on the main form, try:

numRecs = Me!sfrmcontrol.Form.Recordset.RecordCount

This will be a different number for each record on the main form, depending
upon how many records the subform displays for that particular main form
record.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address so that a message will
be forwarded to me.)
- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.

 

[Ken Snell [MVP]]

To add to Gunny's comment, I often use the RecordsetClone object of the
subform to get a record count -- it tends to be more correct because it's
less dependent on needing to "fill" the recordset through a MoveLast action.

The syntaxt is very similar to what Gunny posted:

numRecs = Me!sfrmcontrol.Form.RecordsetClone.RecordCount

 

[Fred Boer]

Dear Ken:

subform to get a record count -- it tends to be more correct because it's
less dependent on needing to "fill" the recordset through a MoveLast

action.

This caught my eye... does "less dependent" and "tends to" mean that you do
or you don't have to do a MoveLast with a recordsetclone? It seems a bit
vague... It would be easier to just use the recordsetclone if it was
guaranteed to work, but your answer doesn't seem to suggest that is the
case.

Cheers!
Fred Boer

 

[Ken Snell [MVP]]

I have never had to do a .MoveLast for RecordsetClone before reading its
RecordCount -- I have lots of code in applications that do not do a
..MoveLast first for the RecordsetClone.RecordCount read, and it has worked
without fail to give the correct count.

You can show this to yourself by opening a continuous forms view form, stay
on the first record, test the Recordset.RecordCount value, then test the
RecordsetClone.RecordCount value.

Don't know if that is 100 guaranteed for all situations, but to me it's not
surprising because the RecordsetClone is created from the Recordset, and I
would assume that Jet has to read the entire Recordset to get the
RecordsetClone, and thus the RecordCount is known.

 

[Ken Snell [MVP]]

And then of course as soon as I post this, I go back and test again on a
small (46-record) table used as a recordsource, and both give the correct
answer.... < g >

But, I do not ever test Recordset.RecordCount and trust it unless I know
that the entire Recordset has been "traversed", just in case.
--

Ken Snell
<MS ACCESS MVP>

 

['69 Camaro]

FWIW, a regular Recordset's RecordCount Property may not be correct until
the cursor has traversed the entire Recordset, but if it's a form's
Recordset, then the RecordCount Property is assigned correctly as soon as
you see the "Record: 1 of 147" in the record navigation section in Form
View. That 147 is from the Me.Recordset.RecordCount Property. (And that 1
is from the Form.CurrentRecord Property.) The form comes up with that 147
by -- you guessed it -- traversing the form's entire Recordset before
displaying this number on the form. That's why it takes so long to display
this number when there are a lot of records in the data source.

Whenever I've tested the Me.Recordset.RecordCount Property in the OnLoad( )
and OnOpen( ) events, the correct number was given, so I haven't had any
problems with it. Admittedly, I've verified this with small data sets (up
to about 3,500 records), not large ones.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

 

[Ken Snell [MVP]]

Good info.

 

[Fred Boer]

Thanks to both of you!

Fred

Good info.

--

Ken Snell
<MS ACCESS MVP>

message news:[email protected]...

 

[Allen Browne]

Gunny, RecordCount will probably give the correct answer for a form bound
directly to a local table.

You might experience the incomplete load (typically zero if none, or 1 if
some) if the form is bound to:
- a SQL statement, or
- a linked table.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

message
news:[email protected]...

 

['69 Camaro]

Thanks for the reminder, Allen. I forgot to mention those caveats.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.