Re: adp vs mdb

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

"'69 Camaro" <ForwardZERO_SPAM.To.69Camaro@xxxxxxxxxxxxxxxxxxxxxx>
wrote in news:#S1LdXFmHHA.4848@xxxxxxxxxxxxxxxxxxxx:

Microsoft now recommends MDBs over ADPs, no matter the version of
Access. I'd take them at their word and use an MDB in all cases.

ADP's have a few advantages over MDB's. That Bill is even
considering ADP's means those advantages are important to him (or,
more likely, his organization), so I'm not likely to tell him
there's never a good reason to use ADP's.

Well, *maybe* it means that. Many people choose ADPs for stupid
reasons, like the fact that it doesn't use Jet.

ADPs are clearly going out the window, so it's a dead-end
development platform

The same can be said for VB6, but it has legions of fans and
development continues years after Visual Basic .Net was unleashed
in the development world. I came from the Unix and VAX world,
where development still goes on on obsolete operating systems,
equipment, and development platforms, because "that's what we have
to work with," not because the vendor decided to make other
products and no longer support older products. Just because the
vendor decides it's a dead-end product doesn't mean every one of
the customers does, too.

But VB6 is a mature development platform with a huge base of users
and a vast array of sources of help and code.

ADPs are very new and never reached maturity. Once MS stops
developing them (if they haven't already), then there really won't
be any reason to keep using them, as there is neither the same kind
of developer community nor the same level of maturity and stability
that VB6 has as a development platform.

Microsoft never finished ADPs, in my opinion. Michael Kaplan's
telling criticisms of ADPs as implemented in Access 2000 were never
really fully addressed by Microsoft.

How important are security considerations - is an MDB
inherently less secure?

An MDB is far less secure,

This seems to me to be confusing issues. If you're choosing a
front end, MDB or ADP (ADPs don't store data, of course), then
the back end is SQL Server, or you wouldn't be able to use an
ADP. Security is then EXACTLY THE SAME between the two.

Since Bill commented about the side effects of an MDB data source
and he currently has an MDB back end, I can't tell when reading
his question whether or not he specifically wanted to know about
security on the front end MDB file or on MDB files in general.
Therefore, I gave the generic answer regarding security on an MDB
file.

But that security question doesn't have anything to do with the
choice of MDB or ADP, though, since ADP is not a choice for his MDB
back end.

If he's considering an ADP, then OBVIOUSLY the back end is
already in SQL Server, no?

No. It's currently an MDB.

But "currently" doesn't matter as the question is about the
*future*, or ADP wouldn't be under consideration at all.

He mentioned "when upsizing from an existing
all-Access mdb to SQL Server" in his first post. He hasn't
upsized yet, but is deciding on a plan of action and wants advice
on which development path to take on the front end. Otherwise, he
would have stated that the back end was in SQL Server and never
mentioned "an existing" mdb.

The question in the subject heading of this thread only comes up
if the back end is SQL Server, so there is NO security difference
between MDB and ADP front ends.

He switched gears within the thread when he commented about an MDB
pulling all records in a table across the network, so I answered
his question in the context of security on MDB's in general,
because the data is going to be set up (hopefully) securely in the
SQL Server back end, which wouldn't make a difference whether or
not the front end was an MDB or ADP.

I think your answer was *very* confusing, as it did not make it
clear that you were addressing a different question than that of the
thread itself.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: Upsizing design considerations
    ... reports, with a ADP, or mdb (actually, it should be mde, or a ADE when you ... you would LINK the tables to sql server, and NOT USE a adp (the reasons is ... the first two remote users ...
    (microsoft.public.access.gettingstarted)
  • Re: adp vs mdb
    ... what about DATA SECURITY? ... not official) in the process of replacing ADP ... Tne .NET framework is simply not relevant to Access development. ... only options for Access development are MDB and ADP, ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Official Status of SQLServer 2005 ADP
    ... solution might be to use ADP. ... With MDB and Linked tables, the only ways of accelerating things are the use ... of Views and the cumbersome use of SQL passthrough queries. ... > SQL Server, and carry on using Access like I aways had. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: ADP Security Best Practices
    ... connection strings for SQL passthrough-- what a fucking joke. ... Interfacing with ADP over MDB DOES HAVE MANY ADVANTAGES ... if you need a real security then you will have to use .NET. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: ADP Security Best Practices
    ... ADP doesn't really offer more than MDB about security and has ... if you need a real security then you will have to use .NET. ... Dear experienced adp - developers, what security mechanisms do you use ...
    (microsoft.public.access.adp.sqlserver)