This is a quick notice to the oratcl community that a new Source
download and Windows prebuilt binaries are available for Oratcl.
Version 4.4 has the following major improvements as well as several
fixes. These are all listed in the ChangeLog file located in the
source download.
Threading:: With the help of Steve Shaw (the hammerora maintainer) and
his valueable assistance, we have eliminated several errors that were
occuring on very fast systems with multiple dual core processors.
Oracle Version: The package has been changed to recognize an
ORACLE_LIBRARY environment variable. This helps alleviate package
loading complications that we had on combined 32bit/64bit systems and
also with different library locations that came about with the release
of Oracle instant client.
Additional Platforms: I spent a considerable amount of time makeing
sure that Oratcl 4.4 works on Linux x86-64 with Oracle 10g R2 (64 bit).
It also works on x86 linux using the 10gR2 instant clients. (with the
ENV variable above set to ../instantclient_10_2/libclntsh.so.10.1
LOBs: Oratcl 4.4 supports the direct reading and writing of blob and
clob columns using SQL. It is now possible to use sql like 'select
clob1, clob2, clob3, clob4 from table_with_clobs' and 'update
table_with_clobs set clob1 = :c1' etc. There are still limitations
however. Depending on the platform there are limits to how big a
Tcl_Obj may grow. I have had little trouble with CLOBS under the 2G
range. You will want to carefully consider your 'oraconfig' settings.
Best if you look at the tests/oralob.test file in the source tree for
examples. I've found that lob piecewise operations of 1,000,000 (1
million) characters work quite well on 64bit linux.
New subcommand [orainfo client]
This command will return 0.0.0.0.0 if the client version is not 10g
or higher.
The OCI function does not exist in the 8i and 9i libraries.
If you have any bug reports, questions or suggestions, stop by the
sourceforge page.
Thanks
Todd Helfter
Robert
Anyone out there using Oratcl on SPARC Solaris?
For years now I've encountered the same problem. I have to hand edit
the Makefile generated by oratcl to add in -R, -L, and -l flags for
1-2 additional oracle libraries. These are libraries that the client library
uses. Since the oracle libraries do not, at least at my shop, get installed
in /usr/lib or even /usr/local/lib , extra work has to go on to allow
oratcl to find them.
I'm wondering whether there is some other way for me to pass that info
along to oratcl during configuration and build.
--
<URL: http://wiki.tcl.tk/ > Indescribable,uncontainable,all powerful,untameable
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
Thanks!
-mi
I don't have time to maintain Sybtcl any more, and I believe DJ is in the
same situation.
Anyone is welcome to step forward and give Sybtcl some TLC and take over
as maintainer.
--
Tom Poindexter
tpoi...@nyx.net
> Anyone is welcome to step forward and give Sybtcl some TLC and take over
> as maintainer.
I may have to do this... The first thing, that bothered me is the limited
number of connections (50) per process. I'd like to make these unlimited --
making the sybtclN objects into sybtcl0xPOINTER objects, so that the actual
address can be parsed out of them (0xPOINTER), instead of using N as the
index into a (preallocated limited) array.
The second problem is the occasional hang in the callback_handler... I
describe it in here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1503300&group_id=33106&atid=407806
Would you be able to comment at all? Thanks!
-mi
Either of those fixes/enhancements would be fine.
Please email me with your SourceForge account id. If you don't have one,
go ahead and sign up. I will add your account to the list of Sybtcl admins,
giving you developer CVS access and control over the Sybtcl project at
SourceForge.
-Tom
--
Tom Poindexter
tpoi...@nyx.net