"Rick Brandt" <ri*********@ho tmail.comwrote in
news:5y******** *******@newssvr 14.news.prodigy .com:
Lyle Fairfield wrote:
>Do you want the list from those who use or have used ADPs extensively
or do you want the list from those who haven't but know all about
them regardless?
Do you feel you would have to own a Yugo for an extensive period
before you could state an opinion about them?
I have not owned, nor used a Yugo and I have no opinion about Yugos. I
believe that a Yugo is some kind of automobile, but I am not sure.
For somewhat similar reasons, I do not comment here about replication or
security.
But I can comment about ADPs, having used them extensively since shortly
after the release of Access 2000 and having sold successful ADP
applications to large corporations, educational institutions and
professional organizations.
ADPs are wonderfully powerful. They have several capabilities that MDBs do
not. In my opinion, their greatest strength is that they both enable and
encourage the developer to use and take advantage of the great strengths of
MS-SQL server.
I have abandoned the use of ADPs for any work beyond quick mark-ups, or
personal use.
I have done this because I feel that ADPs can open data to unrestricted
intervention. To use MS-SQL data with an ADP the user must have logon
authority and permissions to Select, Edit, Delete or Insert Data. Should
the user create another ADP, these permissions will exist for that ADP, and
the user can modify the database without any of the safeguards which the
developer may have built into the application.
To remedy this, MS introduced application roles. When one uses application
roles, it is the application which has permissions, and if the user creates
another ADP, he/she will see nothing and be able to edit nothing, assuming
the user has no permissions. Unfortunately, MS failed to make ADPs and
application roles sufficiently compatible that they can be programmed
without an enormous amount of work (my estimate is 10 to 20 times the
normal amount of work), much of it guess work. The problem with application
roles is that they must be enabled for every connection the ADP makes to
the SQL database, and an ADP makes many, many simultaneous connections. I
have seen as many, (actually I've had a DBA muttering at me) as eight, some
for forms, some for reports, some for list-boxes. In some cases these
connections seem to be made at random. That is the connection the ADP uses
for list-box A on Monday is not necessarily the connection it uses on
Tuesday. (This is probably my imagination; the programming of application
roles is so twisted and arcane that this just seems to be).
One MS book writer on ADPs suggested that developers simply connect by code
and encrypt all the connection information in code in ADEs. I have written
an entire encryption class to deal with this. But I am unwilling to go this
route with an application that I sell; it's unreasonable that I should be
responsible for security of data in a scenario where MS cannot or will not
be.
I do not know if ADPs have been modified in the past couple of years so
that my concerns are no longer valid.
Nothing I have said here should be construed to be a condemnation of ADO.
In my opinion, ADO is a very powerful technology, perhaps the best thing MS
has ever done.
--
Lyle Fairfield
