Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: How does Access 97 rate as a front end?

Re: How does Access 97 rate as a front end?

From: Default User <user_at_jsc.nasa.gov>
Date: 1998/12/28
Message-ID: <3687D8D6.2949ABE3@jsc.nasa.gov>#1/1

My personal experience with Access as a proto-typing tool has been very good. Used as a production tool it has been extremly poor. Access is brutally heavy on the client end and unreliable on the server side. It makes it easy to use non-standard table naming
and SQL, both of which make it hard to port even to other M$ products.

As a front end I personally would never recomend using it. It is extremely taxing on the client machine. VB supports pretty much anything Access can do, and quite a bit that Access can't. If you use the RDO connection methods with VB rather than DAO when talking to Oracle or SQL Server you will see much better performance. RDO is not availible in Access. VB is still heavy on the client compared to Delphi or C++, but acceptable in most cases. VB is less prone to crashes than Access and gives you a great deal more flexability and control over your events and code. VB is not as idiot proof and requires a little more experience to use, but if your talking a production product Access is just about my last choice in what to use as a front end.

My experience is based upon industry work I have done using VB, Access, and Delphi against Oracle, Access, SQL Server, Interbase, and Sybase backends. In every case Access was used we regretted it very quickly. VB was the easiest and quickest to use, Delphi the most powerfull and flexable front ends. Oracle was the most powerfull backend, Interbase was the easiest to use of the back ends.

Anyway thats my two cents on Access.

>since then), Oracle's ODBC drivers for version 8.X were UNABLE TO HANDLE >OUTER

Ouch, that is not a good way to get folks using a product. That fact alone might cause my current client to not upgrade to Oracle 8 just yet. We could re-write the SQL to get around using the sprinkled outer joins in our code but why do that when it works now with Oracle 7.

Tim Romano wrote:

>
> So, if your application is for "casual" ad hoc use with a smallish database (~
> 50mb) then Access might well suffice. But if you have a commercial-quality
> client-server application in mind, then Access won't be suitable.

I wouldn't advise using Access for production products. Too many hassles. Sure you can create a purty form very quickly, but that form will come back to haunt you as the back end crashes repeatedly, or as the out of memory messages pour in, or when you want to port it to a larger more stable back end. Received on Mon Dec 28 1998 - 00:00:00 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US