[AccessD] Hi I am back and stuck

A.D.TEJPAL adtp at hotmail.com
Tue Jun 19 00:49:04 CDT 2007


    You are most welcome Darren!

A.D.Tejpal
---------------

  ----- Original Message ----- 
  From: Darren D 
  To: 'Access Developers discussion and problem solving' 
  Cc: 'ADT' 
  Sent: Tuesday, June 19, 2007 09:29
  Subject: Re: [AccessD] Hi I am back and stuck


  Hi AD

  Brilliant

  I get it - many thanks
   
  Darren
  ------------------

  -----Original Message-----
  From: A.D.TEJPAL [mailto:adtp at hotmail.com] 
  Sent: Monday, 18 June 2007 5:04 PM
  To: Access Developers discussion and problem solving
  Cc: ADT
  Subject: Re: [AccessD] Hi I am back and stuck

  Darren,

      There is no contradiction. When you invoke a recordset (or its clone) directly as form's property, you do not need to set any reference at all - neither to DAO nor to ADO. This is because you are not creating an object related to either of these two libraries, but using an intrinsic feature of the form itself.

      In fact, a single statement, as given below would suffice. There is no need to use the clone and no reference to DAO or ADO is required. If there is no match, there will be no error message (you will simply land up in the first record).
      
      Me.Recordset.FindFirst "ID = " & Nz(Me.CboID, 0)

      Note - Use of Nz() function is necessary - in order to avoid error 3077 "Syntax error (missing operator) in expression" in case of null value.

      As correctly pointed out by Arthur, as soon as you attempt to set an
  explicit recordset object (say rst) for manipulating the form's recordset or its clone, it will be found that FindFirst method is available only for a DAO recordset and setting a reference to DAO is necessary. If due to some reason your db has reference to both DAO & ADO, you should qualify the recordset object suitably (eg. Dim rst As DAO.Recordset).

  Best wishes,
  A.D.Tejpal
  ---------------

  <<SNIPPED>>


More information about the AccessD mailing list