[AccessD] Bind forms to ADO recordset

John,

i've used the approach of collecting the parameters in a form the hides
itself when other objects take the focus but stays available.  It has
public properties that allow various other objects to find out what the
current parameters are and then build their own recordset using the
appropriate parameters.  Each object  that sinks the events of the
parameter form knows when values change and can respond appropriately.
What's wrong with each of them having their own recordset?  You can build a
class to populate a recordset ofbject and just call it from each object,
passing in the recordset object and the parameters needed to populate it.
We did it that way in .Net and I've done it in Access too.


Charlotte Foust

On Thu, Mar 8, 2012 at 10:08 AM, jwcolby <jwcolby at colbyconsulting.com>wrote:

> Darryl,
>
> I use an Active / Trash flag system to allow the users (and my framework
> code) to perform "deletes" which really only set the trash flag and clear
> the active flag.  In the case I am working on right now, Diary records
> (actions that need to be done in the future) are marked completed by using
> a combo with "diary close reasons", reasons that a diary was closed -
> completed, not possible, etc. Only "active" records (not closed) are to be
> pulled into this specific subform.
>
> So that type of thing is what I am trying to accomplish.  The objective of
> course is to pull only filtered records, by parent id, perhaps filtered by
> some other field(s), sorted by field(s) ...
>
> And do so in a consistent programmer friendly way.  IOW I do NOT want to
> be building a SQL statement in OnOpen of every subform, though that is
> exactly how I did so to get this first form working.
>
> I already have a function that I pass in table name, FK field name, fkVal.
>  At the very least this works.  The function builds a dynamic SQL statement
> and assigns it to the ADO recordset object and the form filters.  One
> problem is that for generic use (framework) the parent has to requery each
> and every child form, passing in the PK of the parent, and this has to
> happen on OnCurrent in the parent.
>
> DAO handled all of that for me with the Link child / master properties but
> AFAICT all of that stuff goes away (no longer works) when I try to bind the
> child form to an ADO recordset.
>
>
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> On 3/8/2012 12:35 AM, Darryl Collins wrote:
>
>> One way of doing the pre-processing without any coding etc is to use
>> views in SQL server and refer to them rather than the underlying table.
>>
>> Say you have a very large dataset - use views to break it into logic
>> segments that you commonly use (Say one set of views x Fin Year, Another
>> set x State, or whatever).  That way you can your database behave nice and
>> fast for the user.  For example if they are looking for all sales data in
>> the date range of 1-March-2011 to 30-Jul-2011, you can then search only the
>> view that has that range, rather than the whole darn table.  You can even
>> break it down further to suit your pre-defined queries.  You can also get
>> smart and use union to join up just the views you need if things wrap over.
>>
>> Using this approach can speed things up a lot as the volume of data to
>> search thru is already limited.
>>
>> Cheers
>> Darryl
>>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd>
>
>
> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com>
>
>
>