Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re[2]: Access and Oracle -Reply

Re[2]: Access and Oracle -Reply

From: David White <DWHITE_at_MCCFWC01.SSW.JNJ.COM>
Date: Wed, 28 Feb 1996 14:19:14 GMT
Message-Id: <>

     Some of us have had very good experience with Access 2.0(+) and Oracle
     7.0(+) on multiple platforms (NT on Intel, Unix on Intel, Sun, HP).
     What versions of Access and Oracle and on what hardware have you found
     Access "untrustworthy"?

     David White

______________________________ Reply Separator _________________________________
Subject: Re: Access and Oracle -Reply
Author: ORACLEL (INTERNET.ORACLEL3) at ~SWIFTMAIL Date: 2/28/96 5:35 AM

Sorry folks, I disagree. Too much poor experience with Access to trust it without extensive(!!!!!!) testing in the environment that it will be used in.


On Tue, 27 Feb 1996, Andrew McAllister wrote:

> If permissions are unreliable then it has nothing
> to do with Access. Access cannot subvert Oracle
> security unless you allow it to.
> Ways to trash security using Access:
> 1) Program the security into Access. That is
> make your program responsible for security
> and connect to Oracle with only one user id.
> 2) Attach tables in Access and check the box
> that says "Save login id and password
> locally." Clearly that will allow anyone to
> get access to your tables without a
> password.
> Both of the above are programmer errors.
> I don't mean to flame anyone, but I feel that in
> the past Access has unjustly gotten a bad
> reputation when used with Oracle.
> Access 2.0 is stable, fast enough, and flexible.
> But best of all it doesn't cost a fortune to
> deploy. As an example, our department has deployed
> a MS Access and Oracle application for less than
> $17,000 dollars. That includes the 25 concurrent
> user copy of Oracle (enterprise edition) and
> unlimited runtime copies of Access. Plus each
> machine was purchased with Access installed, so
> each user has the capability of running adhoc
> queries, reports etc. Of course hardware and
> programming time have tipped the scales, but those
> would have been needed no matter what
> client/server platform we used.
> Andy
> Andrew McAllister -- Senior Programmer Analyst
> Office of Research, University of
> Missouri-Columbia
Received on Wed Feb 28 1996 - 14:48:31 CST

Original text of this message