Re: Another angle on this....

Kind of awkward to use a different driver. This is going to go onto 100s now, 1000s later of client PCs at several organisations now and many more later. The technology driver of the port to Oracle is the client consortium already have Oracle server for other stuff that they share and they have an excellent trusted Oracle DBA who they jointly employ so they'd rather not put in another database. I wouldn't either in their position. I don't think I can go to them saying they've got to buy and install and maintain 3rd party ODBC drivers on all their PCs. (unless of course they complain about the speed! then it'll be much easier to take that line if we can show them improved performance)

Regards

"Keith Boulton" <kboulton_at_ntlworld.com> wrote in message news:lldd8.4611$H43.536135_at_news11-gui.server.ntli.net...
> Can you not use a different ODBC driver?
>
> The oracle ones are crap. I'm working with the 8155 odbc driver at the
> moment and reluctant to change because I can work around the bugs in it. A
> search on metalink shows the sort of horrendous bugs present in their ODBC
> drivers. I had a problem with one version where it was clearly ignoring
the
> first byte of returned data *every* time a long column was fetched ie the
> driver cannot ever have been tested by fetching a row containing each of
the
> simple datatypes which is about the simplest test you can imagine..
>
> The MS ones seem to be as bad e.g. you have to install the version 7
> required support files. Trying to invoke a stored procedure caused me all
> sorts of problems....
>
>
> Heinz Kiosk <no.spam_at_ntlworld.com> wrote in message
> news:3Y3d8.3010$Ah1.216103_at_news2-win.server.ntlworld.com...
> >
> > "Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message
> > news:CB%c8.2090$2Q1.6177_at_rwcrnsc54...
> > > <Lots of reasons why rows/second can't be even hinted at snipped>
> > Yeah, it would just be nice to have a hint though.
> > > etc.
> > >
> > > I wasn't calling your application design crap;
> > You didn't. It was me who suggested that possibility.
> > > frankly I know basically
> > > nothing about it. And I am not looking for a consulting job. I have
> seen
> > > enough people with extensive MS SQLServer experience and other
> application
> > > development experience that that there are a set of common errors that
> > they
> > > might make. From that I stated POSSIBLE things that might be wrong.
It
> > is
> > > quite common in the SQLServer world to retrieve all the results at
once
> > and
> > > close the result set and then do things locally on the client. This
> > usually
> > > done because MS consultants say that is the way to do it. (or write
> > > everything in stored procedures and do basically the same thing) What
> > they
> > > are doing is trying to get around a lock problem. (in Oracle readers
> don't
> > > block writers and writers don't block readers - so if I only need to
> > display
> > > 20 rows on the screen I would only get 20 rows and fetch more later as
I
> > > need it. Okay, if my array fetch size is 50 rows then yes I would
fetch
> > 50,
> > > but not the whole result set of lets say 200 or 300 rows. Why? Wire
> time
> > > is much slower than other things in the application. Also why
retrieve
> > more
> > > than I need right now. You said you only retrieve the columns you
need.
> > I
> > > was surprised you said that only because I thought that was a given;
but
> > no
> > > big deal - it is just ensuring clarity - a good thing.
> > I just got an implication that you thought I might daft enough to
retrieve
> > stuff I don't need and I wanted to clarify. My app uses almost exactly
the
> > type of algorithm you describe above for instance when displaying
> scrollable
> > entity-search dialogs or editable scrollable recordsheets of top-level
> > entities, but not for the small c. <100 record recordsets which
typically
> > might be displayed as entity sub-information once you've selected
> something
> > you're interested in. My 50k reference was rather misleading. the
average
> > is more like 20-50 records and the retrieval performance on these little
> > sets is proportionately dreadful. But not the query performance, that's
> > great, even when the query is super-complex the first array-set comes
> flying
> > back at me very quickly. I'll give your driver optimisation suggestions
in
> > your other response some thought (those of them that I don't do
already).
> > They are all good practice regardless of platform and I've considered
some
> > of the ones that I don't do before, but have never felt the need to do
> them
> > because performance is more than satisfactory on all my other db
> platforms.
> >
> > Part of my problem is that in the production environment (as opposed to
> the
> > test environment) I have to turn off ODBC array-fetches because of an
> > obscure bug in the Oracle ODBC driver. Turning them back on improves
> > performance by a factor of 5 so I may risk coding round the bug, which
> I've
> > identified precisely, in the hope that it is as obscure as it seems and
> not
> > systemic or indicative that the feature is not used by others.
> >
> > Regards
> >
> >
> >
>
>
Received on Fri Feb 22 2002 - 04:02:33 CST