Description: On pc Debian x86-64 with master sources updated today, when using Base and editing a table, if I right click on a field which isn't already a primary key, the entry "Primary Key" doesn't appear. Steps to Reproduce: 1. Retrieve simple test database from https://bugs.documentfoundation.org/attachment.cgi?id=102977 (it's an HSQL embedded one) 2. Open the file with Base 3. Edit the only table 4. Right click at left of the second field Actual Results: Context entries appear but "Primary Key" is nowhere to be seen. Expected Results: "Primary Key" entry should be there. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a4522ef5ce6a625054d83ec907aee07c156e94ed CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
We can't either modify the fields of the table as if it was in readonly.
Alex/Robert: would one of you have a bit of time to confirm (or not if I'm missing something obvious) this one?
I built locally 7.6 branch updated today, I don't reproduce the bug.
Could confirm the buggy behavior in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2b6be8af9be3237efc3ed1244302cf899680e97 CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Works well in LO 7.6.1.2 on the same system (OpenSUSE 15.4 64bit rpm Linux.
Thank you Robert for the confirmation. For the record, I don't reproduce this with odb with Firebird embedded.
Not a crash but: - expected to happen on all envs considering the bug - regression - not a corner case
Adding a new field, allows setting up it as primary key.
Just for the record, when opening the odb file, I got: warn:legacy.osl:50033:50033:dbaccess/source/core/dataaccess/ModelImpl.cxx:767: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from! warn:legacy.osl:50033:50033:dbaccess/source/core/dataaccess/ModelImpl.cxx:767: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from! warn:legacy.osl:50033:50033:dbaccess/source/core/dataaccess/ModelImpl.cxx:767: ODatabaseModelImpl::getOrCreateRootStorage: no source to create the storage from! then when clicking on "Tables" pane, I got: warn:legacy.osl:50033:50033:connectivity/source/commontools/dbtools2.cxx:674: No table supplier! warn:legacy.osl:50033:50033:connectivity/source/commontools/dbtools2.cxx:674: No table supplier! warn:legacy.osl:50033:50033:connectivity/source/commontools/dbtools2.cxx:674: No table supplier! warn:legacy.osl:50033:50033:connectivity/source/commontools/dbtools2.cxx:674: No table supplier! warn:connectivity.hsqldb:50033:50033:connectivity/source/drivers/hsqldb/HConnection.cxx:256: DBG_UNHANDLED_EXCEPTION in impl_checkExistingTable_throw exception: com.sun.star.uno.RuntimeException message: "invalid attempt to assign an empty interface of type com.sun.star.sdbcx.XTablesSupplier! at /home/julien/lo/libreoffice/include/com/sun/star/uno/Reference.hxx:105" warn:dbaccess:50033:50033:dbaccess/source/ui/misc/imageprovider.cxx:59: DBG_UNHANDLED_EXCEPTION in lcl_getConnectionProvidedTableIcon_nothrow exception: com.sun.star.lang.IllegalArgumentException message: "Il n'y a pas de table nommée "Table1". at /home/julien/lo/libreoffice/connectivity/source/drivers/hsqldb/HConnection.cxx:266" context: (anonymous namespace)::ProxyRoot ArgumentPosition: 0
(In reply to m.a.riosv from comment #7) > Adding a new field, allows setting up it as primary key. Indeed, when adding a field, the entry appears for this field but: - only this field (not the existing ones) - when saving the table and reopen the table for editing, the entry is not there anymore for the new field
Xisco: would you have some time to do a bibisect? (the pb is quite simple and quick to reproduce).
There are quite weird things I don't understand. Eg: 1) in ODriverDelegator::getDataDefinitionByConnection (see https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/hsqldb/HDriver.cxx?r=0193b284#466) with 7.6, I can see m_aConnections[0] directly on gdb with master branch, gdb tells: Could not find operator[]. 2) same file but in ODriverDelegator::connect (see https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/hsqldb/HDriver.cxx?r=0193b284#349) ptype xOrig indicates: type = class com::sun::star::uno::Reference<com::sun::star::sdbc::XConnection> [with interface_type = com::sun::star::sdbc::XConnection] : public com::sun::star::uno::BaseReference for 7.6 and master => OK but a) once we did this line: 349 Reference<XConnection> xOrig; in master "p xOrig" indicates empty uno::Reference in 7.6 "p xOrig" indicates $1 = {<com::sun::star::uno::BaseReference> = {_pInterface = 0x0}, <No data fields>} b) after 350: in master p xOrig indicates : $30 = uno::Reference to (com::sun::star::uno::XInterface *) 0x55fac13a8f88 in 7.6 $2 = {<com::sun::star::uno::BaseReference> = {_pInterface = 0x5595fbc36ba8}, <No data fields>} That's why ODriverDelegator::getDataDefinitionByConnection fails to find the connection in m_aConnections and that brings all the error messages indicates and finally the lacking option "Primary Key". Now it's a mess to find out what causes this difference, I made a diff between quite a lot of files between 7.6 and master, can't find the culprit for the moment.
I gave a try to bibisect and downloaded the bundle here: https://bibisect.libreoffice.org/linux-64-6.2 => need some time then git clone from this bundle => need some time then tried to follow this https://www.youtube.com/watch?v=6y153Hzu5SQ git checkout master git bisect start master oldest launch soffice with odb file, LO proposes to migrate towards Firebird (experimental isn't active so don't know why) but above all, LO doesn't find Java runtime. I tried to put the same as what I already have for my usual current build, LO doesn't detect JRE. => Stuck, 45 minutes for nothing (and hopefully, I got fiber to download the bibisect package).
My previous logs on gdb were wrong because I had a symbols pb, I had to add "add-auto-load-safe-path" instruction in ~/.gdbinit Anyway I debugged this part in ODriverDelegator::getDataDefinitionByConnection from connectivity/source/drivers/hsqldb/HDriver.cxx: 473 TWeakPairVector::iterator i = std::find_if(m_aConnections.begin(), m_aConnections.end(), 474 [&connection](const TWeakPairVector::value_type& rConnection) { 475 return rConnection.second.second.first.get() == connection.get(); }); see https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/hsqldb/HDriver.cxx?r=0193b284#473) when entering in the comparison part, LO enters include/com/sun/star/uno/Reference.hxx:424 421 // only the query to XInterface must return the same pointer if they belong to same objects 422 Reference< XInterface > x1( _pInterface, UNO_QUERY ); 423 Reference< XInterface > x2( pInterface, UNO_QUERY ); 424 return (x1._pInterface == x2._pInterface); on gdb I go this: (gdb) p x1 $1 = uno::Reference to (connectivity::hsqldb::OHsqlConnection *) 0x55ee6a6f9490 (gdb) p x2 $2 = uno::Reference to ((anonymous namespace)::ProxyRoot *) 0x55ee69fe6ed0 so finally got: (gdb) p (x1._pInterface == x2._pInterface) $3 = false with the patch https://gerrit.libreoffice.org/c/core/+/157178, I got: (gdb) p x1 $1 = uno::Reference to (connectivity::hsqldb::OHsqlConnection *) 0x55b51683b430 (gdb) p x2 $2 = uno::Reference to (connectivity::hsqldb::OHsqlConnection *) 0x55b51683b430 About the change in ProxyRoot::queryAggregation from stoc/source/proxy_factory/proxyfac.cxx, first called is: #0 (anonymous namespace)::ProxyRoot::queryAggregation(com::sun::star::uno::Type const&) (this=0x55b5181d7ea0, rType=invalid uno::Type) at stoc/source/proxy_factory/proxyfac.cxx:295 #1 0x00007ffb4412c0fc in non-virtual thunk to (anonymous namespace)::ProxyRoot::queryAggregation(com::sun::star::uno::Type const&) () at stoc/source/proxy_factory/proxyfac.cxx:345 #2 0x00007ffb4d5bd190 in connectivity::OConnectionWrapper::queryInterface(com::sun::star::uno::Type const&) (this=0x55b518621248, _rType=invalid uno::Type) at connectivity/source/commontools/ConnectionWrapper.cxx:142 #3 0x00007ffb22633d97 in connectivity::hsqldb::OHsqlConnection::queryInterface(com::sun::star::uno::Type const&) (this=0x55b5186211e0, _rType=invalid uno::Type) at connectivity/source/drivers/hsqldb/HConnection.cxx:103 #4 0x00007ffb22633e6c in non-virtual thunk to connectivity::hsqldb::OHsqlConnection::queryInterface(com::sun::star::uno::Type const&) () at /home/julien/lo/libreoffice/instdir/program/../program/libhsqldb.so #5 0x00007ffb22627e89 in com::sun::star::uno::BaseReference::iquery(com::sun::star::uno::XInterface*, com::sun::star::uno::Type const&) (pInterface=0x55b518621200, rType=invalid uno::Type) at include/com/sun/star/uno/Reference.hxx:59 #6 0x00007ffb2263da39 in com::sun::star::uno::Reference<com::sun::star::sdbc::XConnection>::iquery(com::sun::star::uno::XInterface*) (pInterface=0x55b518621200) at include/com/sun/star/uno/Reference.hxx:74 #7 0x00007ffb2264b7bc in com::sun::star::uno::Reference<com::sun::star::sdbc::XConnection>::set(com::sun::star::uno::BaseReference const&, com::sun::star::uno::UnoReference_Query) (this=0x7ffe0dda46b8, rRef=...) at include/com/sun/star/uno/Reference.hxx:285 #8 0x00007ffb226411b1 in connectivity::hsqldb::ODriverDelegator::connect(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x55b51691b2a0, url="sdbc:embedded:hsqldb", info=uno::Sequence of length 5 = {...}) at connectivity/source/drivers/hsqldb/HDriver.cxx:386 so during the connection but also several times after.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aaccb43dad5290cde04b36209ca9fa95d69ba060 tdf#157288: "Primary key" missing when right click a field during table edition It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.