[AccessD] subform bound to ado recordset throws error

RecordsetClone is strictly DAO, so no, it doesn't work with ADO, and
Recordset.Clone is entirely different functionality.  And the master
and child links likewise.  That's part of the reason why I always used
unbound forms/subforms with ADO.  I realize your framework is based on
bound recordsets, but in spite of the fact that after A2k they enable
binding forms to ADO recordsets, it just doesn't work the way you
might expect, so I didn't go there.

Charlotte Foust

On Wed, Mar 16, 2011 at 3:05 PM, jwcolby <jwcolby at colbyconsulting.com> wrote:
> In my framework I do JIT subforms.  Part of the JIT subform process is to
> set the subform binding properties.
>
> I have never used forms bound to ADO recordsets.  It appears that it is a
> known issue that you cannot set the Link Master Field and Link Child Field
> properties of a subform bound to ADO.  Broken, throws an error, doesn't
> work, no fix.  The work around is to filter the subform to only pull records
> for the PK of the parent in the sql that you use to open the recordset that
> the subform is bound to.
>
> So my framework was throwing an error on this code and I had to search
> around to finally find that yep, it doesn't work.
>
> Which means I have to tell my framework's dclsFrm which handles all form
> stuff that the form is bound to an ADO recordset.  And in there somewhere I
> have to figure out a generic way to set the subform's ADO recordset (the
> form will be bound to an ADO recordset) to use a different SQL statement
> (WHERE FKID = Parent PKID) and requery when the current event of the parent
> fires (new parent PKID).
>
> All doable I think, just edits to the framework to adapt to binding to ADO.
>
> Another issue is that the RecordsetClone is hosed when bound to an ADO
> recordset.  I use that to sync my record finder cbo to the form, using the
> ancient code which moves the recordsetclone to the right record, then gets
> the bookmark of the clone and sets the bookmark of the form to that.
>
> Again, nothing that can't be handled, it just doesn't work the same way as
> the DAO bound form.
>
> And I had to find out where all the errors were coming from and figure out a
> way to fix them.
>
> John W. Colby
> www.ColbyConsulting.com
>
> On 3/16/2011 5:31 PM, Charlotte Foust wrote:
>>
>> John,
>>
>> I learned early not to try and mix DAO and ADO in the same routines.
>> I always used the parent form's events to set the source for the
>> subform with ADO.  Maybe I missed the post where you specified the
>> code that was going sideways.
>>
>> Charlotte Foust
>>
>>
>>
>> On Wed, Mar 16, 2011 at 12:36 PM, jwcolby<jwcolby at colbyconsulting.com>
>>  wrote:
>>>
>>> This seems to be a known issue without a resolution.
>>>
>>> http://www.utteraccess.com/wiki/index.php/Using_ADO
>>>
>>> It was occurring specifically when I was trying to use the subform
>>> linking.
>>>  It really appears that when any form is bound to an ADO recordset there
>>> are
>>> a host of issues with the RecordsetClone (which is DAO) and that perhaps
>>> recordsetclone is used internally by DOA to support the form.
>>>
>>> John W. Colby
>>> www.ColbyConsulting.com
>>>
>>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>