On the ADP front - I'd say it's a little unfair to say support for them has been dropped.
Moving to ACCDB isn't really applicable, as an ADP has always been a distinct file format. It used to be the alternative to MDB, now it's the alternative to ACCDB. Nothing's really changed on that front (the new data types in an ACCDB aren't applicable to SQL Server anyway).
(FWIW it's still quite a bit of effort for MS to implement support of ADPs in each new version. So they've not been forgotten about.)
It is true that MS, in general, advocate linked tables as the preferred data access mechanism. But, of course, many developers aren't listening to that.
It's hard to know when, or if, ADP's would be deprecated. I'd suggest that it will be when a viable Access functionality alternative is introduced.
Heh - I hadn't even noticed the reference to my examples until just now. You clearly have impeccable taste LOL.
Nah, seriously (it's sheer coincidence that I happened along actually) there are differences with an ADP. But there's pretty much always a workaround.
For example your errors attempting to manipulate the form's recordset.
In general, it's best to manipulate the recordset - and then re-apply it to the form. (There's little harm in maintaining the opened recordset still - it's the same memory object that the form is pointing to, just the overhead of another pointer).
On the non-updatable selection, it's true that joining to a non-update source will render the whole thing non-updatable.
There are ways around this of course. The later examples working with recordset binding mean you can always fill a different recordset with whatever values you see fit, present that to the user and then write back whatever selections you desire.
Obviously that's more effort than using default binding tricks - but once you leave Jet behind there are a few Access binding tricks that go out of the window.
Cheers.
by: LSMConsultingPosted on 2009-10-16 at 03:45:51ID: 25588248
"1. A basic subform datasheet, that is 'linked' to its parent at the query level (rather than using a filter which seems to be a common method of handling this)"
I'm not sure how you mean this, but you have two methods of handling this: Let Access do it through Master/Child links, or set the Recordsource/Recordset directly in an event of the Parent form. The method you choose depends on several factors, but unless you have a compelling need to do otherwise, let Access handle it.
"2 A subform in which numerous selections can be performed, the data sorted filtered, etc before performing an action on the selected list of rows. "
You can perform whatever you wish on the form, but I'm not sure how that would translate over to your "action".
FWIW, You can use a Stored Procedure to return a Recordset, which you can then use to bind to your form:
Dim rst As ADODB.Recordset
Set rst = New ADODB.Recordset
rst.Open "YourStoredProc", CurrentProject.Connection,
Set Me.Recordset = rst
I have no idea about the "list of values" ...
In regards to the ADP item: you're better off with linked tables. Even MS has dropped support of the ADP format in the newer versions of Access (you can still run them, and even build them, but not if you're using the newer accdb format).