There is a problem with multithreaded OCI programs connecting to an 8.1 database via
an Oracle ODBC driver. A long running query can block all other access to Oracle
from the same application server. We have some Visual Basic programs running on an
IIS webserver which have run into this. When it happens the webserver needs to be
rebooted. The bug database says it will be fixed in Oracle 9.1
ODBC drivers are one of the most fragile pieces of software ever released.
Ian MacGregor
Stanford Linear Accelerator Center
[EMAIL PROTECTED]
-----Original Message-----
Sent: Friday, May 11, 2001 2:00 PM
To: Multiple recipients of list ORACLE-L
Walter,
Are ODBC connections, not really. Are Access connections bad, damn good
possibility.
The problem that I see with ODBC is two fold, 1) there are additional DLL's
needed to make it work and 2) there are soooooooo many ODBC drivers out there.
DLL's are probably the worst of the mess, commonly known as 'DLL Hell' around
here. First they require additional memory on the client machine, and second
the data and sql needs to 'travel' further before heading out the network card.
You also have the problem of having all of the requiset DLL's of the right
version to make things work. OH, you say you installed a new toy this
afternoon? No wonder ODBC isn't working, look here that DLL got replaced!!
This can also cause a significant delay on some slower PC's. The ODBC driver
version war going on is enough to make folks drink! MicroSoft has theirs,
Intersolv gets into the fray, along with Oracle, Sybase, Informix, and on and on
and..... Any package that needs a driver most likely has it's own, like Crystal
Reports. Now one would think that they would all be interoperable, wouldn't
you, but nothing can be further from the truth. Each driver has it's own wierd
behaviors some of which are down right scarry.
As for Access, MS built this little toy as a single user DB for simple
stuff. Sure they built a real slick user interface, which some one at Oracle
would take note. The problem is that people then start developing their own
apps with this beast and try to link in the DB as part of it. Then you end up
with objects you can't manage unless they get the double quote treatement. On
top of that, and I've one of these running around, people will start extracting
data into the Access system and manupulating it therein. Next you get very
angry end users who can't understand why the application is sooooo slow, which
after all MUST be a database problem, Right???
So, ODBC connections I tollerate, their really not bad. But Access is not
spoken here. If you have a problem with an Access application, go find that
developer & yell at him/her.
Dick Goulet
____________________Reply Separator____________________
Author: Walter K <[EMAIL PROTECTED]>
Date: 5/10/2001 11:06 AM
I have been told in the past that ODBC connections to
the database are slow and very resource intensive, but
unfortunately this was not explained. Fortunately, I
haven't really had to deal with ODBC connections much.
However, in my new job, several users are using MS
Access as their query tool and it looks like the
number is growing.
So, are ODBC connections to the database really slow
and a resource problem? If so, why? Also, is there
anything special in regards to the database that I
should be watching or tuning outside of the norm just
because I have a bunch of Access users hitting the
database?
Thanks again for the assistance!
-w
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Walter K
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: MacGregor, Ian A.
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
