Dario Lopez-Kästen wrote at 2004-8-31 18:57 +0200:
... hm.. maybe you are right... though we only use the client libs - oru oracle servers are on Solaris atm.
Here is an selection of a traceback that I got a short while ago:
----- 2004-08-31T18:36:23 ERROR(200) SiteError https://XXXX/search_icon.gif/index_html Traceback (most recent call last): ... "/usr/local/zope/instances/cdks/Products/DCOracle2/DCOracle2/DCOracle2.py", line 1006, in execute result = self._cursor.execute() DatabaseError: (3113, 'ORA-03113: end-of-file on communication channel')
This problem does not look like a Zope or DCOracle problem but like an Oracle problem. When I had to work with Oracle 3 years ago, I have been *VERY* disappointed (this was Oracle 8i). Despite its high costs (100.000 USD), it was almost unfunctional: * memory corruption inside the Oracle client libraries brought our Zope down within minutes of use This was finally fixed by an alternate open protocol. * the Oracle server died often, non-deterministically, after some amount of work we had to regularly close the connection and reopen a new one in order not to let one server do too much work * the Oracle client library caught SIGCHILD making "system" and "popen" unreliable -- this could be fixed with a special configuration option, deeply hidden in the tons of Oracle documentation * full-text reindexing after large imports often crashed non-deterministically * upgrading from one Oracle version to the next Oracle subversion was a nightmare * some combinations of relational and full text subqueries let Oracle forget about its indexes. For example: while a query "Q1 and Q2" took seconds (Oracle recognized that it had indexes) the query "Q1 or Q2" (with the same "Q1" and "Q2") took days (!) (because Oracle had forgotten about the indexes and used full table scans -- which is a bad idea with hundread of millions of records and hundreds of gigabyte of data). The Oracle support was unable to fix this problem within half a year. Oracle recommended to avoid the combination of relational and full text subqueries ! Now, I use Postgres -- and I am *MUCH* happier: I have at most 1 per cent of the problems I have had with Oracle. And this with no costs and no support (but the amount of data is smaller now and there are no full text queries (that were responsible for most of Oracles problems)). -- Dieter