Re: Access awake after 7 years?

After responding to your points below, I find that I do seem to agree with
your assessment that ADPs were a bad idea. Better integration with database
servers, and even ADO might have been a very good idea, but ADPs were not the
way to go about it.

On Sat, 15 Oct 2005 15:11:14 -0500, "David W. Fenton"
<dXXXfenton@xxxxxxxxxxxxxxxx> wrote:

>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.

I was starting to disagree on that, but I don't. Because better SQL Server
integration was a good idea does not mean a separate front-end format that
links directly to a single server instance was a good idea - so I agree.

The separate file format might not have been the only problem, or even the
worst problem, though. There was a huge problem with the spec. I think the
first BIG cause of trouble was MS deciding that because stored procedures are
like JET saved queries, stored procedure results should be editable! To do
that, they had to make modify the ADP spec, plus make sure ADPs could only
ever hope to work with a Microsoft SQL Server back-end. The ADP layer on the
client side has to actually know what table and row each field came from. It
goes downhill from there...

>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.

How many points in there? Anyway, yes, yes, .... and yes.

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

I guess that might have worked, but not while trying to design it around a
pre-existing impementation of SQL Server (which they did - they started with
SQL Server 7). Funny enough, SQL Server 2000 adds a server-side "tabular
function" feature which is a much better option for allowing a client to edit
data returned from a server-side saved query than what they did, which was to
have the ADO client layer go around the server object, and update (or try to
update) the raw tables. Even though ADPs recognize SQL Server "functions" in
A2K2, they treat them just the same as SPs, so that's no help.

>> 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 front-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.

If Access could reliably bind a form to an ADO disconnected recordset,
regardless of back-end, that would be blindingly useful. That's yet a another
simple, valuable possiblity that was not achieved.

>> 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.

I was going to disagree with you on this, but I guess I do agree. I don't
think it was wise to try to eliminate JET as an intermediary to the server at
all - JET provides client-side glue that can be is highly useful and was
stupid to discard. I think, since Access already talks to JET at a lower
layer than DAO, instead of having the Access GUI talk ADO, they should have
enhanced JET to be able to query from ADO sources. Then you could do things
like bind a form to a query that joins a JET table to a SQL Server table, and
edit off-line using a disconnected recordset.

....
>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.

I think it might be overstating to say they started over. I'm sure they tried
to refactor existing code as much as they could. I think, rather, that the
biggest cause of trouble was a very bad spec.
.

Relevant Pages

  • 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: Access awake after 7 years?
    ... I'm not sure I understand what the "idea" of ADPs was supposed to ... 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 ... Server front end solution) on the capabilities of ADO, ...
    (comp.databases.ms-access)
  • Re: ODBC Connections
    ... according to SQL Server Books Online). ... ADPs connect directly ... to SQL Server and do not use JET, so in an ADP the JET limitation does not ...
    (microsoft.public.access.queries)
  • 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)