[AccessD] MoveFirst needed in DAO?

When you open the recordset you're either at the first record, if there are
any, or at EOF, if there aren't. So if you need to know if the recordset is
empty this will also do

Set rst = db.OpenRecordset.......
With rst
  If .EOF Then
    Msgbox "No records"
  Else
    Do stuff
  End if
End With
  
Cheers

Andy


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darryl Collins
Sent: 09 August 2012 08:00
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] MoveFirst needed in DAO?


Thanks Gustav, that is good to know.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Thursday, 9 August 2012 5:07 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] MoveFirst needed in DAO?

Hi Darryl

True, if you need a precise count, you have to do a MoveLast.

However, in most cases I don't care how many records, I just need to loop
these. If you just have opened a DAO recordset, I've never seen anything
else than it was positioned at the first record. Thus, I don't even have to
check for records:

  Set rst = dbs.OpenRecordset(strSQL)
  While rst.EOF = False
    ' do something
    rst.MoveNext
  Wend

because if the recordset is empty, the loop is skipped.
Of course, if the loop runs and you will then run another loop, you then
have to move to the first record:

  If rst.RecordCount > 0 Then
    rst.MoveFirst
  EndIf

So I was just wondering if anyone had experienced situations where the
recordset right after the initial opening was positioned anywhere else than
the first record. It doesn't seem so.

/gustav


>>> darryl at whittleconsulting.com.au 09-08-12 1:34 >>>
In many instances I have need to know how many records are found, to do that
you need to movelast then movefirst.  Especially if you are then going to
loop thru those records.  Of course, often you don't care how many are found
and a >0 count will do.

If I am going to loop I will always put in a  MoveFirst to be sure it is at
the top.  Maybe redundant?

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Thursday, 9 August 2012 12:41 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] MoveFirst needed in DAO?

I've always seen that in a newly opened DAO recordset, the recordset is
always positioned at the first record - IF THERE ARE ANY RECORDS!

So for most recordsets a check to see if any records exist is needed.

Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Wednesday, August 08, 2012 9:17 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] MoveFirst needed in DAO?

In DAO, the newly opened recordset is positioned at BOF but not necessarily
on a record, IIRC.

Charlotte

On Wed, Aug 8, 2012 at 2:09 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi all
>
> Having opened a DAO recordset:
>
>     Set rst = dbs.OpenRecordset(strSQL)
>
> often the first code line following is:
>
>     rst.MoveFirst
>
> or, if the recordset can be empty:
>
>     If rst.RecordCount > 0 Then
>       rst.MoveFirst
>     EndIf
>
> But is that really necessary? At which record could the recordset 
> possibly be positioned if not at the first?
>
> Even a snapshot or an ODBC linked recordset will not - as far as I 
> know - move anywhere until you tell it to do so.
>
> For ADO recordsets it is different as the recordcount can be -1 until 
> you, for example, have done a MoveLast.
>
> /gustav

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



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