Re: A2007 ADPs
- From: "Guy" <Guy@xxxxxxxxxx>
- Date: Tue, 12 Jun 2007 07:50:03 +0800
Dave,
Thanks for your input and clearing up my format misconceptions, although, I
really meant functional format variances.
Agree, any new development I do will probably not be using the ADP format.
Cheers
From a grumpy old software developer or as a fellow newsgroup poster oncomp.object says...
"There is nothing wrong with me that a cup of Draino wouldn't fix" :-)
"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns994C66F7343EAf99a49ed1d0c49c5bbb2@xxxxxxxxxxxx
"Guy" <Guy@xxxxxxxxxx> wrote in
news:e4fIbXBrHHA.4624@xxxxxxxxxxxxxxxxxxxx:
1) Microsoft have introduced a new database format . accdb, does
this mean they are now going to support, or are prepared to
support, 3 different formats all with slightly different features?
Er, what are you talking about? ACCDB is a new version of Jet. It
could have been called Jet 5 and used the MDB format, but the Access
team probably wants to shed the undeserved bad reputation of Jet
(since it's ignorant people that think Jet is bad, this silly name
change may fool them).
An MDB is a Jet database.
An ACCDB is a Jet database.
Both can be used for storing the objects for an application that
connects to any back end.
So, in one sense, it's not really a third format, it's just a
variation of the old Jet format.
On the other hand, if you consider that all versions of Access back
to A2K are supported, you have *four* different formats for
MDB/ACCDB.
But I don't think that way of looking at it makes much sense.
2) The ADP interface does not appear to have been significantly
improved since inception.
Bugs have been fixed and regressed in various incarnations of the
ADP, according to reports from those who were trying desperately to
make use of ADPs.
3) Many of the new features available in A2007 don't appear to be
supported in ADPs.
Just as they aren't supported in MDBs, because they are
ACCDB-specific features. That is, things like multi-value fields are
a db engine feature, not a front-end feature.
4) Commentary suggestes that linked tables are now the preferred
option to talking to non .MDB databases.
That is what MS is saying, and their reason is because there are
just as many inefficient layers between an ADP and SQL Server as
between an MDB and SQL Server.
Can only mean one thing the end of the ADP format, and unless I
hear anything to contary this is what I will be advising my
employer.
I would say that if you have existing ADP apps, keep maintaining
them as ADPs, but do all development as ACCDB/MDB to ODBC.
Thankfully I am currently working towards .NET MCPD (Web
Developer) certification paid for by the company, although, having
said that the amount of (almost) irrelavant information you have
to learn about classes you will probably/may never use for your
70-528 exam is astounding, when I would suggest that a large
majority of the worlds computer applications just talk to
directly/indirectly to an RDBMS database via a form (web based or
otherwise) and most are not writing the next replacement for
Excel. Still, no different from Computer Science at University I
suppose (and not for this newsgroup forum).
The whole point of .NET, seems to me, is stateless data editing,
which is not really what Access apps are about, so I just don't see
how .NET can ever fit into the niche filled by Access apps.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- References:
- A2007 ADPs
- From: Guy
- Re: A2007 ADPs
- From: Vayse
- Re: A2007 ADPs
- From: Guy
- Re: A2007 ADPs
- From: David W. Fenton
- A2007 ADPs
- Prev by Date: Re: ADP (Write to local if loses connection to remote SQL Server?)
- Next by Date: Re: A2007 ADPs
- Previous by thread: Re: A2007 ADPs
- Next by thread: Re: A2007 ADPs
- Index(es):
Relevant Pages
|
