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: <9602281948.AA13073@alice.jcc.com>

     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
     dwhite_at_mccus.jnj.com
     74577.3021_at_compuserve.com


______________________________ 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.

Pete

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
> McAllister_at_grad.missouri.edu
>
Received on Wed Feb 28 1996 - 14:48:31 CST