[AccessD] Bind forms to ADO recordset

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