Steve Jorgensen wrote:
It's not just the develompment time, it's the unpredictability of
runtime
behavior.
[snip]
It's easier to get higher reliability and good performance with an
MDB than an
ADP - period.
Steve,
What are the issues you're talking about here? Or can you point me to a
link that talks about some of them (if they've been discussed
extensively)? I haven't been around the CDMA 'hood for a while; I know
there are plenty of people who argue, and I agree with them, that
learning ADO because it's new doesn't make any sense, but I don't
remember reading much that talks about ADPs being inherintly more prone
to falling over at run time, or inherintly requiring more development
time (other than learning ADO).
This is in no way a troll or a challenge. I've been working on a
project that uses a MS SQL Server back end and an ADP front for the
last seven months, and I've run into very few things that I hadn't seen
in an MDB. Or at least that's my impression--maybe I'm just seeing
trees, though.
Well, for one thing, ADPs have a habit of making certain multi-table queries
uneditable. The first version of a query may be editable, but after some
random and seemingly trivial change in the query itself or afger the next
Access service pack or MDAC upgrade, it becomes uneditable again, and the
tweaking process starts all over again. I've finally gotten to the point
where I don't even try to use multi-table queries on bound forms in an ADP.
Either, I use combo boxes as lookups for data in related tables (uh yeah,
that'll help performance), or have to use separate forms for adding/editing
which is more clicks and work hassle for the user as well as more duplication
of form design elements.
For another thing, there is a bug that was supposedly fixed, but actually
isn't in which sometimes an ORDER BY clause in a subform or subreport causes
an error. To fix it, it is necessary to remove the table name qualifier from
the expression in the ORDER BY clause. Of course, the query builder always
puts the table qualifiers on, and it's never obvious what's broken without
some digging.
In ADPs, any time you do anything slightly out of the ordinary in a
server-side query, the ADP gets confused. For instance, in my MDBs, sometimes
I like to have a view that references a table in another database on the
server. I do this, for instance, to put tables frequently used to hold
temporary data in a database with TRUNCATE LOG ON CHECKPOINT so my backups
aren't filled mostly with irrelevant adding and deleting of temporary data.
When you try to bind an ADP to this, it gets really confused beacause ADO is
smart enough to try to look at the underlying tables, but not smart enough to
look at them in another database on the server.
The ADP looking behind your stored procedures and views also makes it hard to
do things that work fine in an MDB such as using a view for security where the
user has permissions granted via the view that they don't haveon the tables
directly. If you know the issue and are -very- careful, you can work around
this. This is in the category of ADPs trying to think for you and thus making
it very hard to use what should be typical rule enforcement on the back-end.
I can't remember all the other issues right now, but I remember that there are
several more.