In a previous reply (which for some reason my news server is not
showing me), I stated that you can't set a form's .Recordset
property to an ADO recordset. That was an error -- you *can* set it
to an ADO recordset, but so far as I know, that recordset will be
read-only.

To be frank, I don't see much value in setting the .Recordset
property of a form. A form's Recordsource will create the relevant
recordset for the form, but setting the .Recordset property seems
like an awful lot of work for very little benefit.

The only scenario I can think of where it would make sense is one
I've contemplate using but never actually tried, and that's using a
non-editable continuous form as a listview and using a single form
to display the detail of the record selected in the listview. If you
assigned the same recordset to both forms, you'd be saving
resources, whereas if you used the typical method of setting the
Recordsource of each form, you'd be loading two different
recordsets. Then an update to the detail would have to refresh the
list view. If you were editing the same recordset, that refresh
shouldn't be necessary.

I've never tried this, and don't know if one would have to
synchronize bookmarks in the two forms or not, but it always seemed
an intriguing possibility. In the app where I seriously contemplated
it, I ended up having the detail form be completely unbound,
instead, which was certainly a lot more difficult than defining two
bound recordsources, and possibly more complicated than using the
same recordset in two forms.

But I just can't see any justification for setting a form's
recordset when that recordset is being used only by the single form.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/