55  3473 
On Fri, 14 Oct 2005 13:44:43 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote: "lylefair" <ly***********@aim.com> wrote in
news:11*********************@g14g2000cwa.googlegr oups.com:
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.
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.
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. Unfortunately, by trying to do so much
more, ADPs failed to adequately solve even the simplest problems that add the
most benefit.
Steve Jorgensen <no****@nospam.nospam> wrote in
news:6n********************************@4ax.com: On Fri, 14 Oct 2005 13:44:43 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
"lylefair" <ly***********@aim.com> wrote in
news:11*********************@g14g2000cwa.googleg roups.com:
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/articl...000000069.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
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"
<dX********@bway.net.invalid> wrote: Steve Jorgensen <no****@nospam.nospam> wrote in
news:6n********************************@4ax.com :
On Fri, 14 Oct 2005 13:44:43 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
"lylefair" <ly***********@aim.com> wrote in
news:11*********************@g14g2000cwa.google groups.com:
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/articl...000000069.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.
Steve Jorgensen wrote: 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.
Tell us of a specific replicable example where Access cannot reliably
bind a form to an ADO disconnected recordset.
On 15 Oct 2005 21:43:35 -0700, "lylefair" <ly***********@aim.com> wrote:
Steve Jorgensen wrote:
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.
Tell us of a specific replicable example where Access cannot reliably
bind a form to an ADO disconnected recordset.
I'm not going to try to replicate it again, but in several experiments at
different times, it always proved to be more often unstable than stable.
Basically, if you write an application that does anything with an ADO
recordset (disconnected or not) both through code when it is unbound and
through the form when it's bound, you see interface anomalies, like fields not
displaying values that they clearly have, etc. Shortly thereafter, Access
usually crashes and assks if you want to send the error info to Microsoft.
Even without these problems (which are slightly less bad in A2K than in A2K2
actually), there is the problem that Acccess keeps trying to reconnect to the
back-end for no reason. If, for instance, you sort or filter the data, Access
will reconnect, even though these operations seem to be performed on the
client-side with no necessity for a requery.
<aa*********@gmail.com> wrote i think that you guys are crazy
Yes, you have made that clear. I expect many here "return the favor", too.
all the action in the new version of
ACCESS-- it has to do with ACCESS
DATA PROJECTS
What you state is simply not accurate. And, in fact, almost no one who posts
here, other than you, are so bigoted in favor of ADP.
Some liked the idea of a "streamlined SQL Server client", but were turned
off by the impracticality of giving users full access to the SQL Server
tables. Perhaps, however, security is not an issue in your environment (it
has always been an issue in the environmets for which I have developed
database applications).
Some wondered why anyone thought it necessary to fix that which was not
broken (the Access MDB <-> Jet <->ODBC <-> server database approach),
particularly when the unbroken approach allowed Access to be a client to
_any_ ODBC-compliant database. Most of my paying work over the years has
been on Access clients to server databases, and only a minority of the
server databases involved were MS SQL Server.
it is a much more reliable backend for your data
ADPs are not a backend; they are client applications accessing Microsoft SQL
Server (only). There are some workarounds to use classic ADO to access XML
tables, or text files, to simulate/emulate "local lookup tables" (which I
consider to be a distressing shortcoming of ADPs).
i've just had too mcuh stability problems
with a dozen users on Access MDB
I'd guess there are some here who would agree you have some stability
problems. I'd guess there are far fewer competent developers here who would
agree that there are any significant stability problems in a
properly-constructed split Access - Jet multiuser database.
I caution again, aaron, don't bet the farm on ADP / classic ADO / DAP being
"the future of Access".
Larry Linson
Microsoft Access MVP This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Yim |
last post by:
In below codes,
After 10 seconds, function t() was called. So far everything is ok.
Then I want to awake blocked read(). So want to exit program.
In t(), how to do?
(in t(), close(sockfd) don't...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
