Re: ODBC/MS-ACCESS interference with instance

Why use ODBC/ACCESS ? why not use ODBC with SQLnet for Windows and then use any ODBC compliant application and just choose the Oracle 7 data source

Joshua E Lieberman wrote:
>
> Generally, Access only allows updates of Oracle tables with a primary key
> defined, i.e. with an index defined on a primary key. I am not sure why
> any additional indices should be required.
>
> beatonb_at_cadvision.com (Bill Beaton) writes:
>
> >I have got an irate user on my systems, and want to see if this guy
> >has any reason to expect me to satisfy his requests ...
 

> >He is using what appear to be a couple of pieces of crud (ODBC/ACCESS)
> >to develop an application against one of my UNIX server boxes. I
> >created all tables and views per his specification (obviously
> >converting his float, integer and long specifications to the
> >appropriate NUMBER specs). I also created primary key constraints as
> >per his specs.
 

> >Now, he is trying to test, and his data-entry application won't work,
> >because it apparently wants indexes. I am not prepared to create any
> >indices for a number of reasons ...
> > 1. The tables are so small, that indices won't be used for
> > any query or update that I've modelled.
> > 2. I don't want to waste the disk space ... temporarily, it is
> > my most expensive (rare) resource. I actually have most of
> > his tables memory-resident (cached), because they're so
> > tiny (from 100 to 20,000 rows).
> > 3. Are his tools really so buggy that they must have indices
> > created, even tho ORACLE will not use them.
 

> >Does anyone know of ways to force ACCESS w/ODBC to update without
> >the overhead waste of indices? If not, then I'm going to have to tell
> >him to buy a 1/2 Gig drive, which will appear only in his cost centre,
> >and not in the general site's costs.
 

> >Thx for any help,
> >Bill
> >--
> >Names: Bill Beaton beatonb_at_cadvision.com
> > Bill_Beaton_at_calgary.qc-data.com
> >Phone: (403) 295-3254 (Home) (403) 266-8622 (work)
> >Web URL: http://www.tripod.com/~bb61/index.html
 

-- 
BM&×