Created attachment 148384 [details] Screen captures of error and LibO "About" I had been using for a long time a connection to Oracle Database data through Base using the Oracle ODBC Driver and this was perfectly working until I updated to LibreOffice 6.2 (Orignally 6.2.1 and now 6.2.2 but does not change result). I tried to return to LibreOffice 6.1.4 (before installing 6.2, I was running 6.1.2) but, unfortunately any call to display a table, a view or a query ends up with message [ODBC][ORACLE] Optional Feature not implemented. Error displayed is HYC00. I tried to reset my UserProfile but no improvement. I underline that the ODBC driver is fully operational when used from other Windows apllications like MS Excel or MS Access. I tried to re-create a new Oracle ODBC linkage and connect through it but same message appear. Curiously, when testing connection from my Base File properties menu, test is OK.
Created attachment 148386 [details] Screen captures of Oracle ODBC Driver parameters I forgot to highlight that, for compatibility reasons with our ERP system, Oracle Driver is a 32-bit version and i always install LibreOffice in 32-bit version as the 64-bit does not support 32-bit drivers
There's no 6.2.1 or 6.2.2 yet. Just to be sure, there's no problem with 6.1.2 but you've got problem with 6.1.4 and 6.2.0? It could be interesting to have the result with 6.1.3 so we'd know exactly from which LO version the pb appears.
Sorry, my mistake, last updates were 6.2.0.1 & 6.2.0.2 :( I downgraded to version 6.1.2.1 from my original sources refreshing to a new User Profile through the FailSafe menu and I confirm that I have not the above mentioned error launching display of data in Tables, Views or Queries. I then upgraded to version 6.1.3 and error re-appear with this version ...
Ok so the earliest version is 6.1.3.2 and it's a regression.
Hello Thierry, LibreOffice 6.2.2.2 is going to be released today, could you please try again with this version to see if the problem has been resolved meanwhile? Thanks in advance
Dear Xisco, I recently installed in parallel Version 6.2.2.1 and bug is still present in this version. I will try with version 6.2.2.2 when available and keep you posted.
I did a fresh install of version 6.2.2.2 and still get the same error # HYC00 - [Oracle][ODBC]Optional feature not implemented. As before, list of Oracle Schemes, Tables or Views is displayed but error happen when I try to display data of these Tables or Views or Queries registered in a LibO Base file. Note that all queries registered in the Base file are with the "Direct Execution of SQL Statement" feature enabled.
I installed Version 6.3.0.1 - 32 bits and error do not appear anymore! I am again able to display Table data, views or result of queries. Therefore, I change status to "Resolved" / "Fixed"
There hasn't been submitted a fix for this bug. Seems the bug has been gone without fixing. So I changed to "Worksforme"
It be great if a real solution could be provided instead of the workaround to install 32 bit LO. I have multiple users with 64 bit LO installed who can't open dashboards in Base / Calc anymore due to this issue. Latest LO 5 series, 5.4.7.2, 64 bit, works without any issue. Users with LO 6, 64 bit, consistently report 'HYC00 - Optional feature not implemented'.
(In reply to Johan from comment #10) > It be great if a real solution could be provided instead of the workaround > to install 32 bit LO. I have multiple users with 64 bit LO installed who > can't open dashboards in Base / Calc anymore due to this issue. > > Latest LO 5 series, 5.4.7.2, 64 bit, works without any issue. Users with LO > 6, 64 bit, consistently report 'HYC00 - Optional feature not implemented'. What about using a 64 bit driver with LO 64 bits? If there's no 64 bits driver, only 32 bits, it's expected to require LO 32 bits.
(In reply to Julien Nabet from comment #11) > What about using a 64 bit driver with LO 64 bits? > If there's no 64 bits driver, only 32 bits, it's expected to require LO 32 > bits. By default we're using the 64 bit ODBC driver with LO 64 bit. When I remove the 64 bit ODBC driver, install only the 32 bit ODBC driver and create a DSN in the 32 bit windows configuration interface, LO Base responds with: "The specified DSN contains an architecture mismatch between the Driver and Application"
(In reply to Johan from comment #12) > (In reply to Julien Nabet from comment #11) > > What about using a 64 bit driver with LO 64 bits? > > If there's no 64 bits driver, only 32 bits, it's expected to require LO 32 > > bits. > > By default we're using the 64 bit ODBC driver with LO 64 bit. Does this config work? > When I remove > the 64 bit ODBC driver, install only the 32 bit ODBC driver and create a DSN > in the 32 bit windows configuration interface, LO Base responds with: > > "The specified DSN contains an architecture mismatch between the Driver and > Application" If you use LO 64 bits with 32 bit ODBC driver + DSN in the 32 bit Windows conf, I think it can be expected. What about if in this 32 bit case, you uninstall LO 64 bits and install LO 32 bits?
> > By default we're using the 64 bit ODBC driver with LO 64 bit. > Does this config work? No, see above comment. On LO 5.4.7.2 64 bit this works. Since LO 6 64 bit it doesn't work. > What about if in this 32 bit case, you uninstall LO 64 bits and install LO > 32 bits? Haven tested it, but a previous comment(#8) suggests this works. Corporate is pushing 64 bit LO. So this is not really something I can check, nor is this something that scales to the other users.
(In reply to Johan from comment #14) > > > By default we're using the 64 bit ODBC driver with LO 64 bit. > > Does this config work? > No, see above comment. On LO 5.4.7.2 64 bit this works. Since LO 6 64 bit it > doesn't work. > > > What about if in this 32 bit case, you uninstall LO 64 bits and install LO > > 32 bits? > Haven tested it, but a previous comment(#8) suggests this works. Corporate > is pushing 64 bit LO. So this is not really something I can check, nor is > this something that scales to the other users. I think we must focus on the error with full 64 bits or full 32 bits but not with hybrid since expected. The pb is: "HYC00 - Optional feature not implemented" is quite generic and don't provide much hints. Searching about this, I got: 290 Reference< XPreparedStatement > SAL_CALL OConnection::prepareCall( const OUString& /*sql*/ ) 291 { 292 ::dbtools::throwFeatureNotImplementedSQLException( "XConnection::prepareCall", *this ); 293 return nullptr; 294 } See https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/odbc/OConnection.cxx?r=1dd9200b#292 and 450 void SAL_CALL OConnection::setTypeMap( const Reference< css::container::XNameAccess >& /*typeMap*/ ) 451 { 452 ::dbtools::throwFeatureNotImplementedSQLException( "XConnection::setTypeMap", *this ); 453 } See https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/odbc/OConnection.cxx?r=1dd9200b#450 But I expect it fails even if we full 64 bits or full 32 bits install.
From my experience, the 32-bit driver works again with the 32-bit LibO since release of 6.3. The point is that, when extracting a big amount of data (i.e. more that 10000 lines or so), LibO 6.3 or 6.4 in 32-bit installed on my Win10 64-bit OS crashes when saving the files including these extractions making them virtually unusable. As it is very difficult (impossible?) to get both 32-bit and 64-bit Oracle drivers working on the same machine (and our ERP system is designed to work exclusively with the 32-bit Oracle Driver), I then cannot got for a full 64-bit solution. My current work around is to use a parallel install of LibO 6.1 in 32-bit that allows me to save the file after extraction (a bit slow to save the files but, well, it works) and then re-open the file with LibO 6.4 64-bit that allows me to do the calculations and Pivot Tables as the 64-bit does not crash when saving these big files (and is also quicker than the 32-bit edition). For the crashes in saving big Calc files with 32-bit version, I have never been able to identify the reason. The file closes without any message, WinDebug installed and used as detailed in the WiKi, gives no backtrace and when tracing the use of memory and CPU's, nothing looks wrong. Usually, the progress bar goes quickly to around 90% of progress and then very slowly before everything collapsed before the last percents of the bar were reached. I did fresh reinstall, delete my profile, tried to adjust memory parameters, tried to close all other applications to free up all capacities but all were, until now, unsuccessful. In my tests, I also tried with a file only with extracted data and no other calculation or spreadsheet but he results the same. I just noticed that the status bar message shown seems always the same : "calculating cells height ..." I never found a way to disable this "cells height adjustement" and therefore have not been able to confirm if this is the reason for the crash.
Thierry: do you have a machine on Linux to give it a try? If not, ideally, it could be useful to build sources with debug (enable-dbgutil) see https://wiki.documentfoundation.org/Development/BuildingOnWindows. Of course, I know it takes some time to retrieve prerequisites (Visual C++, Cygwin, etc.), download sources, build... I build Lo sources on a Linux machine with enable-dbgutil but I don't have Oracle DB. I know there's Oracle Express but it's 2GB download and am not even sure I may install it without pb on Linux Debian. Moreover, I suppose it needs some config/tuning.
I do have Linux machine but at home and not connected to the Oracle System at my work. So, I cannot give it a try :( Regarding a possible build, I had a quick look into the link you provided and this looks a process a bit beyond my own capabilities ... As a workaround, do these build sources need to be machine-specific or would it be possible to use one of yours with the enable-dbgutil option to test on my work computer that runs under Win10? Regarding Oracle Drivers, yes these need some config/tuning and it has got a bit dificult nowadays as Oracle has limited access to most of its knowledge database.
(In reply to Thierry Menigoz from comment #18) > ... > Regarding a possible build, I had a quick look into the link you provided > and this looks a process a bit beyond my own capabilities ... It's more a matter of time rather than a complex thing. > As a workaround, do these build sources need to be machine-specific or would > it be possible to use one of yours with the enable-dbgutil option to test on > my work computer that runs under Win10? I'm on Linux too at home but even if had Win10 at home, I wouldn't know how to create an enable-dbgutil build. > > Regarding Oracle Drivers, yes these need some config/tuning and it has got a > bit dificult nowadays as Oracle has limited access to most of its knowledge > database. I wonder why some try to migrate away from Oracle... :-) Xisco: any idea how to provide a Win10 debug master build? I don't see it on https://dev-builds.libreoffice.org/daily/master/ ?
On Win10 64 bits with master sources updated today, I could open an Oracle DB with ODBC. I installed "Oracle Instant Client Basic" + pack "ODBC Oracle Instant Client" Here extra steps I did: - unpack "Oracle Instant Client Basic" in C:\oracle\instantclient_19_6 - unpack "ODBC Oracle Instant Client" in C:\oracle\instantclient_19_6 - create subdirs: C:\oracle\instantclient_19_6\network and C:\oracle\instantclient_19_6\network\admin - created a file Tnsnames.ora in C:\oracle\instantclient_19_6\network and C:\oracle\instantclient_19_6\network\admin - filled Tnsnames.ora by taking example from https://www.orafaq.com/wiki/Tnsnames.ora - modified system env var path to add "C:\oracle\instantclient_19_6" - created a new system env var TNS_ADMIN : C:\oracle\instantclient_19_6\network\admin - restart PC so sys var envs changes are taken into account - create User datasource Then I created a brand new odb file and use ODBC connection + require password, selected the connection and tested it ok. Finally, I could open a table but noticed this on console: warn:legacy.osl:11208:1336:connectivity/source/drivers/odbc/OConnection.cxx:68: Failure from SQLDisconnect
Created attachment 160021 [details] bt Windows (windbg) Here's a bt when trying to close table.
I noticed that some functions weren't implemented in ODBC: - setFetchDirection - getBinaryStream - getCharacterStream - getArray - getClob - getBlob - getRef - updateLong - hashBookmark Thierry: just for the test, do you reproduce the crash with a table containing just a key field (NUMBER) and a test field (VARCHAR2)? Indeed, I just wonder if it could be due to a type which would need a non implemented yet function. Before testing, give a try to recent (if possible last one) ODBC Oracle driver, see https://bugs.documentfoundation.org/show_bug.cgi?id=122779#c20
Lionel: I'm not sure the bt I retrieved corresponds to the Thierry's crash since it's not at the same moment but it seems we still got ressource management (that's why I put these 2 other tdfs in cc). Any thoughts?
So, if I skimmed correctly, this bug is not anymore about "optional feature not implemented", but about a crash when getting "a lof of data" now?
(In reply to Lionel Elie Mamane from comment #24) > So, if I skimmed correctly, this bug is not anymore about "optional feature > not implemented", but about a crash when getting "a lof of data" now? There are perhaps 2 bugs (related or not I don't know): - error message, Optional Feature not implemented. Error displayed is HYC00. - the crash I retrieved
For the "optional feature not implemented", does the button "more" on the error message give any more information?
The backtrace looks like a crash in the deletion of m_pRowStatusArray. Weird, unless the ODBC driver takes ownership of the pointer when we pass it... which would be *really* unexpected.
Thierry, could you try without the "force WCHAR" option in the driver?
(In reply to Lionel Elie Mamane from comment #26) > ... > The backtrace looks like a crash in the deletion of m_pRowStatusArray. > Weird, unless the ODBC driver takes ownership of the pointer when we pass > it... which would be *really* unexpected. I tested several things: 1) I put in OResultSet dtr: osl_atomic_increment( &m_refCount ); m_pSkipDeletedSet.reset(); m_pRowStatusArray.reset(); osl_atomic_decrement( &m_refCount ); since m_pSkipDeletedSet is initialized with m_pSkipDeletedSet.reset( new OSkipDeletedSet(this) ); Same thing 2) I also tried to convert unique_ptr to simple pointer like in OStatement osl_atomic_increment( &m_refCount ); m_pSkipDeletedSet.reset(); delete[] m_pRowStatusArray; osl_atomic_decrement( &m_refCount ); Idem I also tried to add: setStmtOption<SQLUSMALLINT*, SQL_IS_POINTER>(SQL_ATTR_ROW_STATUS_PTR, nullptr); before deleting or reset, idem. It doesn't crash only if it's simple pointer and no delete[] (but I suppose it would leak here) with all mechanism of dispose, release, close, weak ref, component helper, Reference, dtr + the fact that ODBC driver does its own ressource management and LO must adapt to it, it's not easy to disantangle all this.
Dear Thierry Menigoz, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Thierry Menigoz, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp