Making a field invisible after checkbox (1 Viewer)

Gasman

Enthusiastic Amateur
Local time
Today, 07:25
Joined
Sep 21, 2011
Messages
5,949
Yes, but if EOF is true upon opening it, there are no records ... I think.
And, (I think), that is what he is talking about. People testing for EOF and BOF at the same time immediately upon opening the recordset, which wouldn't make much sense. Who knows. Perhaps God himself will step down and clarify this extremely trivial tit for tat we are having.
Yes, that was what I was trying to infer, badly perhaps. :(
 

Micron

AWF VIP
Local time
Today, 02:25
Joined
Oct 20, 2018
Messages
3,084
Apologies to prakashdl if he/she thinks we took this post off the rails. Perhaps it wasn't all for nothing.
 

Gasman

Enthusiastic Amateur
Local time
Today, 07:25
Joined
Sep 21, 2011
Messages
5,949
The method is Allen Browne's (I presume you know who that is) so if he says that's the way to do it, it is good enough for me.
I also know who he is. :)
However as this logic was already in COBOL74 I was keen to test, as I have see the test for both time and time again for Access.
I like many others, find some code and use it all the time, however for this particular logic, I was intrigued as to why Access would be different?

So I tried this short bit of code?

Code:
Sub testEOF()
Dim rst As Recordset
Dim strSQL As String

strSQL = "Select * from table1 where 1=0"
Set rst = CurrentDb.OpenRecordset(strSQL)
Debug.Print "EOF " & rst.EOF
Debug.Print "BOF " & rst.BOF

Set rst = Nothing
End Sub
 

Micron

AWF VIP
Local time
Today, 02:25
Joined
Oct 20, 2018
Messages
3,084
Can't see the debug.print results?

You probably can simply test that the record count is not zero (not the actual count), but it is possible for an empty ADO recordset count to be -1, so why bother having a method for each when you can have a method that works either way?
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 02:25
Joined
May 21, 2018
Messages
3,180
There are a couple nuances that does not make this completely clear. In this demo it provides the value of EOF and BOF in a popup.
1)Start with an empty form and it shows BOF and EOF are true as expected
2) Now create a couple of new records only, and look at the value of BOF and EOF (BOF and EOF remain true regardless of how many records aded. I would expect BOF to be false.)
3) Now move back a record
4) Delete all records and check BOF and EOF (BOF and EOF are false with no present records I would expect true)
These situations confused the crap out of me recently.
 

Attachments

pisorsisaac@gmail.co

Active member
Local time
Yesterday, 23:25
Joined
Mar 14, 2017
Messages
897
Interesting.
Maybe, (this is an untested guess), similarly to the well known need to MoveLast on dao recordsets before a true Count can be obtained, maybe there is something to be said for MoveLast and MoveFirst before BOF or EOF can be accurately obtained, in special cases where you are talking about records being added to a form. Or something like that.

Random fact: i keep promising myself i'll leave this thread alone, but i keep breaking that promise. AWF is addictive! :LOL::ROFLMAO::ROFLMAO::LOL:
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 02:25
Joined
Feb 19, 2002
Messages
28,992
Yes, maybe it does, but it just seems more sense in the load event in case of a form without a current record.
Maybe just me in keeping with the way I think of bound vs. unbound forms. Nothing earthshaking. :)

EDIT: I just tested it and found that the Current event does indeed fire even for an unbound form. Never really tried or wanted to use Current for an unbound form, but it's cool to learn something new, I guess..;)
Why are you assuming this is an unbound form?
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom