Re: Access awake after 7 years?

Steve Jorgensen <nospam@xxxxxxxxxxxxx> wrote in
news:6n51l19l5ba9bmjcu98n7f7lp9nk93m07o@xxxxxxx:

> On Fri, 14 Oct 2005 13:44:43 -0500, "David W. Fenton"
><dXXXfenton@xxxxxxxxxxxxxxxx> wrote:
>
>>"lylefair" <lylefairfield@xxxxxxx> wrote in
>>news:1129256956.721411.94940@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
>>
>>> Sadly, I agree; ADPs were a great idea; they seemed to be
>>> wonderful.
>>
>>I don't see that ADPs were ever a great idea. The whole
>
> A crappy implementation does not make a great idea into a bad one
> - it's just crappy execution.

I'm not sure I understand what the "idea" of ADPs was supposed to
be, I guess.

>>justification for them seems to me to have been to avoid the icky
>>old Jet db engine. That so patently stupid an idea that I
>>dismissed ADPs on the front end, without ever needing to waste
>>hours, days and weeks trying to make them work.
>
> That might have been a motivation. What I personally wanted out
> of ADPs, and why I tried to use them, was to have a more seemless
> environment for doing development on applications that already had
> good a reason to be client/server, not to start writing apps as
> C/S that I would not otherwise have done that way.

I don't see why MDBs couldn't have had features added to interface
better with SQL Server, rather than throwing that out and starting
over to build the whole damned thing.

Also, so far as I understand it, ADPs depend for much of their ease
of use with SQL Server (and I note again the fact that it doesn't
even pretend to be a generic C/S front end solution, but just a SQL
Server front end solution) on the capabilities of ADO, which from
what I've read, seem to me to too "black box," making too many
decisions for the user so that you end up struggling against ADO's
assumptions about your data just as you did with Jet.

Had they designed a SQL Server-specific data provider, instead of
using a generic data access layer, perhaps that could have been
avoided.

> For instance, in an MDB, it's hard to impossible to make a bound,
> editable form based on a SQL statement written in Transact SQL
> dialect to take advantage of Transace SQL features.

So why did they choose to invent an entirely new fron-end format to
implament that, instead of altering the way MDBs work to allow that
to happen? I mean, they pushed the ADO integration for MDBs, too,
but it seems that MDBs don't really have much in the way of actual
features that are delivered via ADO functionality, after all. Surely
that would have been an area where ADO could have delivered
something that Jet/DAO couldn't.

> Unfortunately, by trying to do so much more, ADPs failed to
> adequately solve even the simplest problems that add the most
> benefit.

It seems to me that it was an unwise decision to try to implement
additional C/S (i.e., SQL Server) functionality by building an
entirely new front-end building platform, instead of by simply
redesigbing the old one to reflect the new environments in which it
can be used.

It could be that any of the single tasks that are such a benefit
would be much, much more difficult to implement in MDBs than in a
freshly designed format, but you'd save all the time of
re-implementing all the things that already *so* work in MDBs.

I'm reminded here of Joel Spolsky's article on why Netscape's
decision to chuck the existing codebase and start over was such as
bad idea:

Things you should never do, Part I
http://www.joelonsoftware.com/articles/fog0000000069.html

Seems to me that this is exactly what Microsoft did with ADPs --
threw it out and started over, instead of fixing the existing
codebase.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
.

Relevant Pages

  • Re: Access awake after 7 years?
    ... your assessment that ADPs were a bad idea. ... servers, and even ADO might have been a very good idea, but ADPs were not the ... Because better SQL Server ... like JET saved queries, stored procedure results should be editable! ...
    (comp.databases.ms-access)
  • Re: ADP Vs. ODBC
    ... which ADPs made much harder. ... SQL Server, I found that ADPs were far and away better than the ... Going from DAO to ADO (my first ... recordset with a WHERE clause), and doesn't work except with Jet ...
    (microsoft.public.access.adp.sqlserver)
  • Re: ADP Vs. ODBC
    ... been something fundamentally flawed in the underlying design. ... People keep telling me about how ADPs don't work, ... and since I wasn't doing any SQL Server ... I began the switch to ADO. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: ADP Vs. ODBC
    ... well as many holes, i.e., things that MDBs made easy, and which ADPs ... I've never been an Enterprise developer, ... When I upsized to SQL Server, I found that ADPs were far and away better than the clunkiness of using linked tables and pass-through queries. ... Going from DAO to ADO required a fair bit of re-coding, then going from ADO using Index/Seek (since I'd been misled as to the capabilities of ADO w. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Connecting Access MDBs to SQL databases
    ... >>> With all the recent discussions on ADPs and their lack of ... >> In Control Panel you set up a DSN that points to the SQL Server ... >DSN-less connect string in the IN clause of a saved querydef and use ...
    (comp.databases.ms-access)