ADP Ready for Prime Time?

[Guest]

MDB is dead.

ADP is alive and well.

ADP reports SLAUGHTER crystal reports in usability.

ADP is an awesome platform for data entry

 

[Guest]

i believe that i am the person that made the depecrated statement... not
sure

ADP rocks.

Microsoft isn't taking this platform seriously; and they need to.

The bugginess of ADP is probably holding up a LOT of SQL Server sales, I
would assume.

 

[Steve Jorgensen]

So why were we using Access again? Being able to edit in continuous forms is
one way we make user interfaces easier to use, by not making user have to
switch contexts all the time. It's also a way we can use to keep from
duplicating the same controls on multiple forms, this keeping application
complexity down.

If I'm designing an application where you only update one row at a time, I
might as well use a more powerful programming language with weaker bound UI
capabilities.

views are a pain to update

so basically use base tables

and get this

1) only load a single record at a time and this should cut down on
complexity

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.

 

[Steve Jorgensen]

So basically, ADPs are a way to do what MDBs can already do pretty well, only
with more things that don't work or are very flakey. OK, the ability to edit
server-side objects through the Access UI is great, but you can use an ADP for
server-side object development, and use the MDB for all the production
front-end forms, reports, and code.

ADPs are ready for primetime.

but they're difficult to implement, especially things like this:

1) forms against views is difficult/unpredictable
2) stored procs bind well to form, but it isn't very well documented
3) sql server doesn't have a crosstab query (yet)

hth

 

[Steve Jorgensen]

i believe that i am the person that made the depecrated statement... not
sure

ADP rocks.

Microsoft isn't taking this platform seriously; and they need to.

ADPs might rock if they did and fixed what's wrong with ADPs today, but MS
won't, so ADPs don't.

 

[Lyle Fairfield]

1) only load a single record at a time and this should cut down on
complexity

Yes, I agree. ADPs are way better when one does not use the parts which don't
work consistently well. Throw out forms and reports and you have a
masterpiece.
This strategy also cuts down time spent in learning to almost nothing.

 

[J. Clay]

I rarely if ever use continuous forms for editable data. I use them to
display data only and with a click on the continuous subform record I bring
the info into a data entry area of the main form. This allows for much
better control of the data entry process. It is also consistant with
applications we have used in the past.

On of the biggest benefit to ADP and working in access is that quick forms
and reports. I do think that to fully utilize the power of ADP you do need
to be willing and able to code quite a bit more, but it is still
significantly less than other development platforms due to the ease of
form/report layout.

ADPs do work different from MDBs, but in my case the difference is a
definate possitive. As for developing in another language. 1) I don't have
studio and don't want to spend the money on it. 2) I know Access & VBA and
can pretty much do any thing in it I want. 3) I do use bound forms and
capabilities related to them.

Jim

So why were we using Access again? Being able to edit in continuous forms is
one way we make user interfaces easier to use, by not making user have to
switch contexts all the time. It's also a way we can use to keep from
duplicating the same controls on multiple forms, this keeping application
complexity down.

If I'm designing an application where you only update one row at a time, I
might as well use a more powerful programming language with weaker bound UI

capabilities.


views are a pain to update

so basically use base tables

and get this

1) only load a single record at a time and this should cut down on
complexity

On 18 Jan 2005 05:41:56 -0800, (e-mail address removed) wrote:

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.

 

[Larry Linson]

Yes, I agree. ADPs are way better
when one does not use the parts
which don't work consistently well.
Throw out forms and reports and
you have a masterpiece. This strategy
also cuts down time spent in learning
to almost nothing.

ROFL!

 

[Tim Ferguson]

Yes, I agree. ADPs are way better when one does not use the parts
which don't work consistently well. Throw out forms and reports and
you have a masterpiece.

What is left?

Tim F