Not to be the great defender of ADPs (as they're not a preferred technology of mine either - I've hardly ever used them really) but I don't think we can state, as if fact, that they're a dead end quite yet.
Sure we all have our preferences, mine also lie with MDBs. And it's very true in that ADPs haven't been advanced feature-wise, and are less obviously visibile under 2007 - but the fact remains they have not been (and there's no official indication from MS that they are due to be at any specified date) deprecated.
They were bug fixed and updated in Acc2007 - just receiving no new features. Indications are this will continue.
Eventually yes I do believe they will come to an official end, naturally - everything will ;-) But yes I do believe that whatever successor of MDB/ACCDB we have in years to come will outlast the ADP. (Hopefully by many years!
But there are developers (I can think of one MVP off the top of my head) who are still dedicated to their use.
I wouldn't say they're dead. I wouldn't say they're dying. I'd say they're not feeling very well though. <g>
It isn't exactly fair to say that moving to ACCDB has affected ADPs though really. The change in file format (to what is the immediate successor of Jet) is exclusive of the ADP. The Jet engine was never present at all in ADPs previously - and the ADE isn't present still and so has no role in supporting them.
MS had stated that they would not change the Jet MDB format again - so when changes were needed in Jet they kinda had no choice but to move format (and file name). ADPs weren't so constrained - had there even been any advancements the change in file format (and hence name) wouldn't have been relevant or required. (ADP's are all FE development tool anyway - by definition).
One of the things about Access (and what I prefer about the MDB/ACCDB format) is the number of choices is offers.
So - sticking with ADP or not there's generally a way to battle through.
If you're not long into your trek into ADPs and you're more comfortable with MDBs (and DAO in particular) then it might indeed be worth your time to revert while there's no great loss to your time investment.
As Pat says - just because you're using linked tables and passthroughs - doesn't mean you can't still leverage ADO. It can easily be used in an MDB to offer effectively the same direct server execution of commands as an ADP.
Indeed since 2007 has scrapped ODBCDirect support from DAO - I feel ADO is at least as important as ever - despite MS's attempts to subtly steer away from it again.
As Pat also says though Passthroughs - even as they stand as read only, parameterless queries - are a very powerful part of Access.
Efficient and versatile. Though they can't accept parameters directly in the sense that native Jet queries can - the standard methodology when working with SQL Stored Proc executions which require parameters (or even just dynamic T-SQL) is to very simply alter the SQL source of the passthrough at runtime before executing them (or even just creating them on the fly).
And yes - SQLDMO is just as usable from an MDB/ACCDB. It's just another library to reference.
