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: Oracle ODBC driver vs OO4O...

Re: Oracle ODBC driver vs OO4O...

From: Jim Kennedy <kennedy-family_at_attbi.com>
Date: Fri, 19 Apr 2002 14:19:34 GMT
Message-ID: <CHVv8.71648$G72.53938@sccrnsc01>


Actually in the tests I have done 0040 is much faster than ODBC (and I find it less complex, but that is a matter of what you are used to) My guess is that you didn't use bind variables, you kept opening the cursor, and you did not optimize the field access as is suggested by the on line help. I have found it to be very fast if I : 1. use bind variables.
2. Open the cursor once and subsequent times just set the bind values and refresh the result set.
3. Add the field access optimization per the optimization section in the on line help.

I try to use all the capabilities and performance enhancements that a vendor gives me (provided they are useful to the task at hand) and not dumb down the database because other vendors "don't do that". Heck I paid for all those capabilities why not use them!

Jim

"John Calder" <john_at_pixieware.com> wrote in message news:a9opes$f6i$1_at_lust.ihug.co.nz...
>
> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message
> news:ib0ubu8l8orfbrmadkfodirtdeb1fvbp9i_at_4ax.com...
> > OO4O is a *native* Oracle specific driver.
> > It doesn't have the overhead associated with ODBC
> > Further comments unnecessary.
> >
>
> Do you speak from experience of actually running practical tests on them
> yourself for your systems and circumstances?
> It worries me when I read this kind of thing that we in our industry
> "evaluate"
> by reading, talking and listening to salesmen, while we forget that the
> great technical advances in recent human history have come from the
> renaissance idea to test it and measure it for real (Galileo and co)
rather
> than just believing everything authorities say.
>
> So my approach to coming to Oracle as a newbie is to get out my stopwatch,
> set an identical task (a set of SELECTs ) for the objects on offer
> and time them.
>
> ODBC came out fastest for reading data, and there was not
> the hassle with Oracle Proprietary syntax to deal with CLOBs:
> they just came through as big strings as I wanted.
> Main ODBC problem: I hit a brick wall with the INSERT statement
> with error "ORA-01704"= cannot insert more than 4000 bytes
> which does come as a shock to me when I have been happily
> inserting more, much more, than 4000 bytes with INSERT statements
> on many other database engines.
>
> OO4O looks to be the hardest to program, and will give me
> major incompatibility problems with code I want to use against
> other database engines besides Oracle, but it is becoming
> increasingly clear from my experiments that I am going to be
> forced rather unwillingly into using it because it is the best writer.
> I am now struggling with
> ways of building generic code that can gather column metadata
> in advance so it knows which fields require the strange-to-me
> methods for CLOBs
>
> The Oracle OLEDB provider was the easiest to use in my
> tests, reasonable for read speed, easy to program for write,
> but very very slow at writing.
>
> I tested OLEDB and ODBC by Oracle.
> It became very clear very quickly that the Microsoft-produced
> ODBC and OLEDB efforts are limited in their capability
> and I could not take them seriously for any of my purposes.
>
> I need to retain some compatibility with PICK and similar
> database engines so that means a lot of work with long strings.
> Can you recommend anything published on the web on
> Oracle and strings over 4000 bytes long? ( which seems to be
> a whole different area of programming from mainstream Oracle work)
>
> > OO4O is a *native* Oracle specific driver.
> > It doesn't have the overhead associated with ODBC
>
> From studying its behaviour, and its own documentation, I am
> guessing that its purpose is as a showcase for new Oracle
> data models, methods and methodology as much as for speed.
> It even looks to me that it has just as much overhead as ODBC,
> just an Oracle-proprietary style of overhead.
>
>
>
>
Received on Fri Apr 19 2002 - 09:19:34 CDT

Original text of this message

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