[AccessD] Code stops working

Yes, and that fails as well.  BOF AND EOF is impossible in anything but
an empty recordset.  If the pointer is at both BOF and EOF it is because
there are no records in between.  In ADO, it's the only way to check for
an empty recordset because the record pointer is set to the opposite
position as in DAO, so you can't just check for one the way you can in
DAO.  The code has worked for years checking for an empty recordset
before trying to manipulate it.  Now I've had to fall back on "If Not
rst.EOF Or rst.Recordcount > 0 Then" which is ugly but at least doesn't
return bypass the code when there are records in the recordset and
doesn't drop into it when there are none ... So far. 


Charlotte /foust

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Tuesday, April 04, 2006 10:53 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Code stops working

Hi Charlotte

Have you tried with

If Not (rst.EOF = True And rst.BOF = True) Then

Also, I know this construction is widely used, but I've never seen it
necessary to check for BOF when opening a recordset, only when you
possibly step up beyond record 1.

/gustav

>>> cfoust at infostatsystems.com 04-04-2006 19:10:13 >>>
Has anyone else seen this?  We have code that has worked for 3 years and
suddenly, it fails.  The code can be very simple like "If Not (rst.EOF
and rst.BOF) Then"  and even though both EOF and BOF evaluate to true,
the next line of code will execute!  I've seen this in several places.
And we have signature handling in one of our apps.  The subforms, which
all have the same kind of code, raise a custom event which is sunk by
the parent.  On some subforms, the event may raise the first time but
not after that.  Making a change in the code in either the child or
parent might make it work ... Once.  Then it returns to ignoring the
raise event line.  It steps through it, but the event is never sunk in
the parent form.  The exact same code works in other subforms.  I've
tried compact and repair, decompile, creating a new form and copying the
controls over, then exporting the code from the odd subform to text and
pasting it into the module for the new form.  Same behavior.  These are
very complex subforms and the parent form is worse.  

I just recently upgraded to Office 2003 on my machine (we're still using
Access 2002) and I'm wondering if that has caused the strange behavior.
The others in my office have had 2003 for a while, but I dragged my
heels on it.  We're also working in VS 2005 and have the latest source
safe version, so it may be an ugly combination of things, but has anyone
else had a similar experience?  Code that worked on Friday was broken on
Monday!  Yikes!

Charlotte Foust
Infostat Systems, Inc.


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com