thorsten <[EMAIL PROTECTED]> writes: > > I didnt have any luck compiling the website downloads of Carob 0.5.1 > and ODBSequoia 0.5.1a either. I recieved a different error message: > > connect.cpp: In member function 'SQLRETURN > ODBSeqNS::ODBCConnection::connectw(SQLWCHAR*, SQLSMALLINT, SQLWCHAR*, > SQLSMALLINT, SQLWCHAR*, SQLSMALLINT)': > connect.cpp:156: error: 'DEBUG_LEVEL_DEBUG' was not declared in this scope > make[1]: *** [connect.o] Error 1 > make[1]: Leaving directory `/home/thorsten/Desktop/odbsequoia-0.5.1a/src' > make: *** [lib] Error 2
Sorry about that, I missed this carob API change. I just released odbsequoia 0.5.2a which should be fine. > I have successfuly compiled the CVS versions, however the behaviour is > completely erratic: > Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to > allocate -1208360143 bytes) in /var/www/odbctest.php on line 25 > > 1.2GB!!!! > > On further testing, i recieve different output from the > script. Sometimes the script works and returns the correct row values, > however it never onces returns the column names correctly and always > seems to have a snippet of error message, such as: Metadata like for instance getting column names is not yet implemented in the ODBC driver. > Any insights? This is most definitely not something i can even think > about putting into production at this point. The ODBC driver is indeed not production ready yet, many features are still missing. However it should not crash like this. It is likely that PHP ignores ODBC errors and goes on with corrupted values. On the other hand the carob + libmysequoia libraries have been extensively tested and are production ready. The main purpose of the libmysequoia library is precisely to allow the use of sequoia from PHP, and libmysequoia has been tested using PHP (among others). Could you give it a try instead of odbsequoia? > I've attached the php script i've been using, but i dont believe there > is anything special within it. Any intermediate layer usually adds extra calls and more generally complexity, leading to issues difficult to diagnose. It is very likely that PHP uses some not yet implemented ODBC features. We would GREATLY appreciate if you can run your simple PHP test case again with ODBC and carob logs enabled, and send them to the list (provided it's not too big). To begin with, which ODBC driver manager are you using? Carob logs are sent by default on stderr. Can you run your PHP script from the command line in order to get those logs? unixODBC logs can be enabled like this: [ODBC] Trace = Y [Sequoia] TraceFile = /tmp/odbc.log Check this documentation: <http://www.unixodbc.org/odbcinst.html> Thanks a lot in advance. _______________________________________________ Carob mailing list [email protected] https://forge.continuent.org/mailman/listinfo/carob
