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>>