Jim Lawrence
accessd at shaw.ca
Fri Mar 18 05:57:34 CDT 2011
Hi Charlotte: It appears that I may have never actually used this recordsetclone, never knew the function existed and now I will never have an opportunity to use it again. For that reason I was confused and thought you were discussing recordset.clone. It is sad to know some poor function died before I had a chance to abuse it. ;-) Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust Sent: Thursday, March 17, 2011 4:46 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] subform bound to ado recordset throws error The recordset produced by recordset.clone is not the same as the recordsetclone. If you modify RecordsetClone, the change is reflected in the recordset. When you create a recordset using clone, the original and the clone do not interact in that way, or at least they didn't in the versions of Access with which I actually worked (through 2002). Charlotte Foust On Thu, Mar 17, 2011 at 1:57 PM, Jim Lawrence <accessd at shaw.ca> wrote: > Hi Charlotte: > > If that was true why does the following not product an error? > > <code> > Dim rsAccounts As New ADODB.Recordset > > Set rsAccounts = LetterProcessing(typeCmpConfig.CompanyCode, strGroup).Clone > > </code> > > Jim > > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust > Sent: Thursday, March 17, 2011 11:13 AM > To: Access Developers discussion and problem solving > Subject: Re: [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 >> > > -- > 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 > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com