Hello !
OCILIB v3.4.1 will be available by next monday (2009-11-23).
The SourceForge SVN will be updated with the last sources this weekend and release packages available on SourceForge by monday.
This release only contains bug fixes and minor changes that could not wait for v3.5.0 that has been developed for last few month.
Here is the changelog of the 3.4.1 :
2009-11-23 Version 3.4.1 Vincent Rogier vince.rogier@gmail.com * Native 64 bits fixes - Fixed Direct Path API - Added casts + modified some variables types * PL/SQL support fixes - Segmentation fault could happen when using OCI_Date binds in PL/SQL statements - Binds values for OCI_Date and big_int variable where not updated after OCI_Execute for PL/SQL - OCI_ServerGetOutput() : ouput was broken if statements PL/LSQL statmeent/blocks were re-executed - OCI_ServerGetOutput() : trash string was returned if the number of amonut of output lines was greater than the value of the <arrsize> parameter of OCI_ServerEnableOutput() * Miscellaneous fixes - OCI_ImmediateFmt(), OCI_PrepareFmt(), OCI_ExecuteStmtFmt(): trailing character of formatted string representation of dates was missing on non windows plaftorms - OCI_ObjectGetColl() : the internal OCI Collection handle of the returned OCI_Coll object was invalid and thus caused segfault when calling OCI_Coll functions afterward for these objects - OCI_DateNextDay() : On unixes platforms+Unicode builds -> wrong value passed to the OCI internal call * Miscellaneous changes - OCI_RefToText() : parameter size is now if type <unsigned int> instead of <int> - Modified : OCI_BIND_MAX (maximum number of binds for a statement) is now 1024 by default instead of 512 - Added Oracle spatial demo source (demo/geometry.c)
Next version, v3.5.0, is a massive internal rewrite for handling different types of strings.
At the moment, OCILIB handles string as :
- char * (OCI_CHARSET_ANSI) - wchar_t * (OCI_CHARSET_UNICODE) - mixed mode for char * statements and wchar_t * user data (OCI_CHARSET_MIXED)
I implemented a portable way to use wchar_t on all platforms (but a real pain internally!) as OCI handles Unicode string as fixed 2 bytes UTF16.
On MS windows, that’s good because Microsoft C runtime implements wchar_t as UTF16.
On most of unixes, wchart_t is 4 bytes and OCILIB uses internal buffers when talking to OCI and pack/unpack data from/to user strings.
All of that works well…. But when working in Unicode mode on unixes with big resultsets or binds, performance can suffer of internal conversions (even if the internal routines are quite efficient)
So, I decided to refactor OCILIB charset modes as follow :
OCI_CHARSET_ANSI OCI_CHARSET_UTF8 OCI_CHARSET_UTF16 OCI_CHARSET_UTF32
For backwards compatibility, OCILIB v3.5.0 defines :
OCI_CHARSET_UTF16 if user has defined OCI_CHARSET_UNICODE on MS Windows
OCI_CHARSET_UTF32 if user has defined OCI_CHARSET_UNICODE on unixes
The new mode OCI_CHARSET_UTF8 internally initializes OCI in UTF16 and performs conversion on the fly when needed to not loose surrogates.
These new modes would allow an Unix programmer to pass its own UTF16 strings (from a third party lib or from its own implementation) to OCILIB with better performances.
And a programmer that want to use native wchar_t would still be able to do so (using the actual OCILIB implementation).
To summarize, OCILIB users will be able to chose the type of strings that they want to use between ANSI, UTF8, UTF16 and UTF32 whatever the platform
Have a nice week end !

Recent Comments