To my knowledge, ADP have not been removed from Access 2007; however, it's
appears that they are now totally screwed in term of speed.   .

I have done all of my tests with the Beta version and I must repeat them
with the RTM to be sure; however, some messages that I've read in the
newsgroups share the same conclusion.   See for example:

http://groups.google.ca/group/microsoft.public.access.adp.sqlserver/browse_frm/t
hread/826016f026f0eeee/385419790b476f53#385419790b476f53

(Short story on my previous tests with the beta version: when running in a
virtual machine with 256Megs of allocated memory, I had to kill the whole
job to regain control of my PC and while running it with 512 Megs allocated,
it was a slow crawl.  Profiling on the SQL-Server showed that the cause was
an incredible amount of queries made about the properties of objects on the
SQL-Server and that these queries was repeated each time the mouse was moved
from field to field and even inside a field in the case with 256 Megs of
memory allocated.  No problem at all when running a MDB file in the same
VM.)

So you should move the ADP feature from the What's gone section to the
Totally Screwed section.

Great article, Allen -- I really appreciate the work you've put into
preparing it.

Of coures, I have questions! :)

1. rich text: is the HTML *good* HTML, or the usual trashy, awful MS
stuff, with complex and idiosyncratic CSS? Is the HTML controllable?

2. minor spelling hint: under the embedded macros item, you mean
"deprecate" instead of "depreciate". Same for the big
"compatibility" section at the end.

3. the "features removed" section: I still object to the way people
are   treating this. Security and Replication and ADPs have *not*
been removed from Access -- they were just omitted from the new
database format. Unless you're a moron, you won't just automatically
start using the new database format, right? What you mean is
"removed from new database format".

4. continuing from #3: In regard to replication, saying "Use
attached tables, connected to a database that has replication" is
rather misleading, as that's the way replication should have been
used in previous versions of Access, too, since only tables should
be replicated. I think it's misleading on all three of these issues
to not explicitly say that if you use MDB/ADB format you continue to
have all the functionality of previous versions of Access (it's only
DAPs that have actually been removed and can't be created in A2K7,
if I understand correctly).

5. Autofill: that was an A2K and later feature, so doesn't apply to
all previous versions (significant numbers of developers still do
lots of work in A97, and I barely remember the Autofill feature,
since I don't do too much data editing in table view in A2K and
later).

6. Imports: have that made it work better for Excel? That is, can
you now control the data types better than before, instead of having
to make sure the spreadsheet is absolutely properly formatted before
the import?

7. Compatibility Issues: is that an issue in converted MDBs as well
as in new ACCDBs?

8. Should I Buy section: I think that new users ought not buy it
unless they have no outside dependencies. That is, they aren't going
to share data with other users and don't have any existing
applications with a developer working on them. I just think an
unqualified "YES" is way too optimistic. Of course, I guess I'm
thinking more in terms of your second category. I still think the
first category oughn't be an unqualified affirmative, but a MAYBE. I
also just don't believe in the "learn it for the future" advice, as
that was the advice everyone gave for ADO when it was introduced in
Access. I didn't learn it, and, well, I have no regrets on that,
since Microsoft wised up and it's now deprecated in Access.

Overall, from what you've written, it seems to me that A2K7 is a
disaster similar to A95 -- much worse than A2K.

But, again, thanks very much -- I'll be using your article to try to
steer any of my clients away from buying A2K7.

Great analysis and write up, Allen. Thanks for your hard work on this!

--
Smartin

Hi Allen,

We have an A2000 ADP app that runs in our branch offices in 100+
countries.  A2000 was a great technology for us, but it is time to move
on.  I was really looking forward to A2007, and was glad to see that
ADP continues to be supported.

Then the bad news.  The first time I opened a form bound to a simple
stored proc like:

CREATE PROCEDURE dbo.spselTableName
AS
SET NOCOUNT ON
SELECT * FROM dbo.TableName

Where TableName is a simple reference table with less than 10 fields
and a dozen records, It took more than a minute to open!  I put a trace
on to see what was happening, and I noticed loads of code like this:

select object_name(sotblfk.id), user_name(sotblfk.uid),
object_name(sotblrk.id), user_name(sotblrk.uid) from sysreferences
srfk,
sysobjects sofk, sysobjects sotblfk, sysobjects sotblrk where
srfk.constid =
sofk.id and srfk.fkeyid = sotblfk.id and srfk.rkeyid = sotblrk.id and
user_name(sofk.uid) = N'dbo' and object_name(sofk.id) =
N'FK_ForeignKeyTableName_TableName_PrimaryKeyFieldName'

It looks like A2007 is interpreting the foreign key relationships in
the SQL database.  In our SQL 2000 database (1400 tables, about 3000
relationships) each of these calls generates about 100,000 reads.  That
is really, really nasty.  It is even worse in SQL 2005.  A2000 never
did this, so the same form is lightning fast in A2000, but dead slow in
A2007.

What happened??  IMHO, this problem kills ADP as a usable technology
for corporate development.  The most attractive upgrade path for us
would have been A2007, but now we are looking at a complete re-write of
our app.  Not so nice.

Any suggestions?

Thanks,
Francois Louw

yeah how f.cking DARE you spread misinformation on ADP?

we should have _HELPED_ the JAPS invade your wimpy-a.s 'country' in WW2

-Aaron