By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,985 Members | 1,861 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,985 IT Pros & Developers. It's quick & easy.

ADP Issues

P: n/a
Hello,

Someone had told me that there was "a list" of known issues with the Access
Data Project. I like using the ADP at this point, and haven't had any
issues yet, but would like to know what those issues are. Does anyone have
a link or a list of any issues using ADP?

Any help would be appreciated.

Thanks!
Rick
Oct 17 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"Rico" <me@you.comwrote in news:e79Zg.158571$R63.153800@pd7urf1no:
Someone had told me that there was "a list" of known issues with the
Access Data Project. I like using the ADP at this point, and haven't
had any issues yet, but would like to know what those issues are.
Does anyone have a link or a list of any issues using ADP?
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?

--
Lyle Fairfield
Oct 17 '06 #2

P: n/a
Hahaha, Now you know my plight with the NGs! Why those who have used them
extensively of course.

Rick
"Lyle Fairfield" <ly***********@aim.comwrote in message
news:Xn*********************************@216.221.8 1.119...
"Rico" <me@you.comwrote in news:e79Zg.158571$R63.153800@pd7urf1no:
>Someone had told me that there was "a list" of known issues with the
Access Data Project. I like using the ADP at this point, and haven't
had any issues yet, but would like to know what those issues are.
Does anyone have a link or a list of any issues using ADP?

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?

--
Lyle Fairfield

Oct 17 '06 #3

P: n/a
Lyle Fairfield wrote:
"Rico" <me@you.comwrote in news:e79Zg.158571$R63.153800@pd7urf1no:
>Someone had told me that there was "a list" of known issues with the
Access Data Project. I like using the ADP at this point, and haven't
had any issues yet, but would like to know what those issues are.
Does anyone have a link or a list of any issues using ADP?

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?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Oct 17 '06 #4

P: n/a
"Rick Brandt" <ri*********@hotmail.comwrote in
news:5y***************@newssvr14.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

Oct 17 '06 #5

P: n/a
I suppose that I should mention that I have not entirely given up on
ADPs. The latest ADPs allow the "setting" of both Form, Report and (I
believe) drop-down recordsets to ADO recordsets. Because these ADO
recordsets can be disconnected, they present new possibilities to form
editing, including, for continuous forms, the editing of multiple
records and then the saving or abandoning of all changes.
So it strikes me that one could create an ADP without any base
connection at all and connect all forms etc using standard modules and
encrypted logons and permissions in ADEs. I haven't pursued this enough
to know if it's viable but I have a hobby-oriented geocaching
application I want to create and that may be a suitable situation in
which to experiment.

Oct 17 '06 #6

P: n/a
On Tue, 17 Oct 2006 20:50:25 GMT, Lyle Fairfield
<ly***********@aim.comwrote:

This is true, but it is certainly not exclusively so for ADP's. It
seems to me all programming environments that perform significant work
behind the scenes to support data binding can be affected. For example
VB6, Access MDB + ODBC, ASP Data Environment.

I wonder if A2007 will be any better in this respect.

AppRoles are not essential for all situations. Databases have been
used for decades without this feature.

AppRoles and ADP: http://support.microsoft.com/kb/308312
I agree with you that the limitations are pathetic and MSFT should be
ashamed about the poor level of integration of two tools from the same
shop.

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

Oct 18 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.