[AccessD] Master/Detail Classes in Access

It is read-only in A2K but not in 2002 or after.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 3/26/2012 11:40 AM, Kenneth Ismert wrote:
> Arthur,
>
> I did a web search on the issue, and found no way to directly populate
> an unbound continuous form from generic VBA objects in Access 2007.
>
> I did see several references to populating continuous forms from ADO
> disconnected recordsets. This is 'unbound' in the sense that the data
> is retrieved only once from the datasource, with none of the 'dynaset
> style' polling for real-time data changes. However, this is inherently
> read-only.
>
> There was a post on UtterAccess with a download on how to do this:
> http://www.utteraccess.com/forum/Recordset-Unbound-Contr-t1424758.html
>
> To edit, you would have a single-record unbound form that loads its
> data from the selected record on the continuous form. The unbound form
> would handle all of the data editing/adding/updating, and signal the
> continuous form to requery if a change was made.
>
> So, in the absence of a more authoritative answer from someone else,
> that is what I would suggest.
>
> -Ken
>
>> Arthur Fuller:
>> Subject: Re: [AccessD] Master/Detail Classes in Access
>> This would be for unbound forms, and more particularly for SQL Server as
>> the BE.
>>
>> On Fri, Mar 23, 2012 at 3:57 PM, Kenneth Ismert<kismert at gmail.com>  wrote:
>>
>>> Arthur,
>>>
>>> Without more details, it is hard to know how to advise you.
>>>
>>> If these forms are bound, the recordsets themselves are object
>>> abstractions of the data. I see little point in creating an object
>>> wrapper for a base object, if all you are going to do is simulate
>>> functionality that the base handles perfectly well.
>>>
>>> But if the forms are unbound, I don't know off the top of my head if
>>> you can create multiple rows in the subform using just a collection of
>>> generic objects. Maybe this is a recent feature. Still, you might be
>>> better off binding the subform to a disconnected recordset, and again
>>> use the built-in functionality to navigate.
>