Created attachment 85423 [details] Testdatabase with only a little table Open the attached database. There is only one table with one row and two columns. Open also a new Calc-document. Mark the table from the database and try to copy it by drag and drop to the Calc-document. A symbol appears, that the data would be copied. Since LO 3.5.0.beta0 this way of copying data doesn't work any more. A dialog appears: "No connection could be established". Remember that copy and paste will work well. One hint: With this version the path to the user-profile in Linux had been changed to .config/libreoffice instead of .libreoffice. Don't know if this could be a reason ...
Confirming also on Mac OSX 10.8.4 with : Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 Adding Lionel to CC Alex
Adding other Base bug QAers/devs to CC
Works fine in : LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1 Alex
On pc Debian x86-64 with master sources updated today + brand new LO profile, I reproduced the problem. (I tried to drag and drop the whole table without even opening it). Here are console logs I noticed: 1) At opening of the DB file 3 times this: warn:xmloff.core:32584:1:xmloff/source/core/xmlimp.cxx:848: exception caught warn:legacy.osl:32584:1:xmloff/source/core/xmlimp.cxx:849: caught an exception! in function:virtual void SvXMLImport::setTargetDocument(const com::sun::star::uno::Reference<com::sun::star::lang::XComponent>&) type: com.sun.star.lang.NotInitializedException context: N8dbaccess17ODatabaseDocumentE 2) warn:legacy.osl:32584:1:sc/source/core/data/document.cxx:4797: SelectionPattern Null warn:legacy.osl:32584:1:sc/source/core/data/document.cxx:4797: SelectionPattern Null warn:legacy.osl:32584:1:sc/source/core/data/document.cxx:4797: SelectionPattern Null warn:legacy.osl:32584:1:svx/source/form/dataaccessdescriptor.cxx:359: ODataAccessDescriptor::operator[]: invalid acessor! warn:legacy.osl:32584:1:connectivity/source/commontools/dbtools.cxx:1713: dbtools::askForParameters XSQLQueryComposer is null! warn:legacy.osl:32584:1:connectivity/source/commontools/dbtools.cxx:1715: dbtools::askForParameters XConnection is null!
( Thank you, Julien, for saying "without even opening it". Yesterday I was trying to drag and drop from the Data View, and I achieved only my own confusion. ) I have succeeded in reproducing Julien's messages in a debug build of master. For comparison, LibreOffice brings over both the column headings and the data if I right-click > Copy on the table name in Base and then right-click > Paste in Calc. In gdb I put breakpoints on throw and catch with short backtrace on each. The last throw/catch pair reported before the program displays the "No connection ..." message box shows, with linebreaks added: Catchpoint 1 (exception thrown), 0x005090e5 in __cxa_throw () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #0 0x005090e5 in __cxa_throw () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #1 0xad837928 in dp_manager::ExtensionManager::check (this=0x8796680) at /home/terry/lo_hacking/git/libo2/desktop/source/deployment/manager/ dp_extensionmanager.cxx:1491 #2 0xad837800 in dp_manager::ExtensionManager::removeModifyListener (this=0x8796680, xListener=uno::Reference to (XInterface) 0x878b41c) at /home/terry/lo_hacking/git/libo2/desktop/source/deployment/manager/ dp_extensionmanager.cxx:1481 #3 0x07eb06ad in LngSvcMgr::stopListening (this=0x878b3f8) at /home/terry/lo_hacking/git/libo2/linguistic/source/lngsvcmgr.cxx:553 Catchpoint 2 (exception caught), 0x00507da6 in __cxa_begin_catch () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #0 0x00507da6 in __cxa_begin_catch () from /usr/lib/i386-linux-gnu/libstdc++.so.6 #1 0x07eb06ff in LngSvcMgr::stopListening (this=0x878b3f8) at /home/terry/lo_hacking/git/libo2/linguistic/source/lngsvcmgr.cxx:555 #2 0x07eb073d in LngSvcMgr::disposing (this=0x878b3f8) at /home/terry/lo_hacking/git/libo2/linguistic/source/lngsvcmgr.cxx:566 #3 0x0096adcd in cppu::OInterfaceContainerHelper::disposeAndClear (com::sun::star::lang::EventObject const&) () from /home/terry/lo_hacking/git/libo2/solver/unxlngi6/installation/opt/ program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 HTH, Terry.
git bisect shows: 3ca9241defd7d7a2f10d87586fb32818e76df094 is the first bad commit ... source-hash-ceb55cd688cebede8cef8408540019fe54528869 and git bisect log shows: # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect bad 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # bad: [598083cdb5699e7f45183da8b750815f62ff5485] source-hash-ecb1599ad00e71dfe05f3ae9a71bdce5f7540a40 git bisect bad 598083cdb5699e7f45183da8b750815f62ff5485 # good: [7a67618d4eb83613b68e348711ae303d7a37f217] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e git bisect good 7a67618d4eb83613b68e348711ae303d7a37f217 # bad: [1fd146a6cc80f3a3c2a14d3971501b67fece30a6] source-hash-817bf1d41bb07aeb3ed7649d25c2b44ee4acb1fe git bisect bad 1fd146a6cc80f3a3c2a14d3971501b67fece30a6 # good: [49797665f56766854b6d49d551e2e3bddb482399] source-hash-f2972242673cc9608960e9ca70e82766be5275e3 git bisect good 49797665f56766854b6d49d551e2e3bddb482399 # good: [977ef3fe8edd7d517a45d7df573f5afa7b79cc3d] source-hash-ab407ad86610a0aba882b03075319e0b62b2c8d3 git bisect good 977ef3fe8edd7d517a45d7df573f5afa7b79cc3d # bad: [3ca9241defd7d7a2f10d87586fb32818e76df094] source-hash-ceb55cd688cebede8cef8408540019fe54528869 git bisect bad 3ca9241defd7d7a2f10d87586fb32818e76df094 # good: [a059dc3aa6f025fcff113c166b081946def03190] source-hash-55c5ea43a59e505297fb6fa20b77aaa28f7c67bc git bisect good a059dc3aa6f025fcff113c166b081946def03190 In git log, I notice: commit 7e8eb75aea745146d7d12df70c4f5ca8f3648ed3 Author: Eike Rathke <erack@redhat.com> Date: Mon Nov 28 02:40:30 2011 +0100 dr78: #i116426# use ODataAccessDescriptor for database import parameters, support bookmarks for selection # HG changeset patch # User Niklas Nebel <nn@openoffice.org> # Date 1294842009 -3600 # Node ID e25621ed7fd31753eea52ee5ff3f0a6d170db9a9 # Parent 5ea5624904a5aa39bb40ce197c80a0a41f40b873
(In reply to comment #4) > 1) At opening of the DB file > 3 times this: > warn:xmloff.core:32584:1:xmloff/source/core/xmlimp.cxx:848: exception caught > warn:legacy.osl:32584:1:xmloff/source/core/xmlimp.cxx:849: caught an > exception! > in function:virtual void SvXMLImport::setTargetDocument(const > com::sun::star::uno::Reference<com::sun::star::lang::XComponent>&) > type: com.sun.star.lang.NotInitializedException > context: N8dbaccess17ODatabaseDocumentE This is probably innocuous; I get this all the time. > 2) > warn:legacy.osl:32584:1:sc/source/core/data/document.cxx:4797: > SelectionPattern Null > warn:legacy.osl:32584:1:sc/source/core/data/document.cxx:4797: > SelectionPattern Null > warn:legacy.osl:32584:1:sc/source/core/data/document.cxx:4797: > SelectionPattern Null > warn:legacy.osl:32584:1:svx/source/form/dataaccessdescriptor.cxx:359: > ODataAccessDescriptor::operator[]: invalid acessor! That's probably the real problem. Need to go up in the stack when this one happens and see where it comes from. > warn:legacy.osl:32584:1:connectivity/source/commontools/dbtools.cxx:1713: > dbtools::askForParameters XSQLQueryComposer is null! > warn:legacy.osl:32584:1:connectivity/source/commontools/dbtools.cxx:1715: > dbtools::askForParameters XConnection is null! I guess these two are consequences of the above.
(In reply to comment #7) > > warn:legacy.osl:32584:1:svx/source/form/dataaccessdescriptor.cxx:359: > > ODataAccessDescriptor::operator[]: invalid acessor! > > That's probably the real problem. Need to go up in the stack when > this one happens and see where it comes from. The problem is I can't control mouse or keyboard in the Linux session which includes LO and gdb when I try to retrieve a bt at this precise moment. The only thing I can do is "Ctrl-alt-Fn" to switch virtual terminal and then kill LO or gdb to get control back.
Created attachment 85860 [details] bt during operator function I found a workaround for my gdb problem, I gave several commands to gdb, like this: gdb soffice.bin $LOPID -ex 'b dataaccessdescriptor.cxx:359' -ex 'c' -ex 'c' -ex 'bt' (twice 'c' because I got a intermediate segfault which gives a column of "?")
Created attachment 85872 [details] typescript with backtraces from warnings "SelectionPattern Null" I have collected three backtraces from the warning "SelectionPattern Null". Points of possible interest: (*) My LibreOffice is master commit 9e9693b, fetched 2013-009-03, configured with --enable-dbgutil. (*) My line issuing the warning is document.cxx:4786; I have not looked into the reason for the different line number. (*) The program issued the warnings after I took menu option File > New > Spreadsheet in window Test.odb and before the program presented "Untitled 1". The backtraces are at lines 179, 435, and 697 of the typescript. (*) The program issues the same three warnings when I execute it with --calc on the command line. HTH, Terry.
After having added some logs, I found that the fole "svx/source/form/dataaccessdescriptor.cxx", method "sal_Bool ODADescriptorImpl::buildFrom( const Sequence< PropertyValue >& _rValues )" was giving this duing my tests: DatabaseLocation : <Any: (string) file:///home/julien/compile-libreoffice/bugs/69091_alex_robert/Test.odb> ActiveConnection : <Any: (com.sun.star.sdbc.XConnection) 0x68a1040> Command : <Any: (string) Table1> CommandType : <Any: (long) 0> Notice: "DatabaseLocation" whereas the method void ScDBDocFunc::UpdateImport( const String& rTarget, const svx::ODataAccessDescriptor& rDescriptor ) in sc/source/ui/docshell/dbdocfun.cxx contains this: 1701 rDescriptor[svx::daDatabaseLocation] >>= sDBName; 1702 rDescriptor[svx::daCommand] >>= sDBTable; 1703 rDescriptor[svx::daCommandType] >>= nCommandType; So after having replaced this line: rDescriptor[svx::daDataSource] >>= sDBName; by this: rDescriptor[svx::daDatabaseLocation] >>= sDBName; I succeeded in importing the table. Lionel: should I gerrit submit this patch or do you think it's not the good way?
(In reply to comment #11) > Lionel: should I gerrit submit this patch or do you think it's not the good > way? Finally, I think it's more simple to gerrit submit and let everyone judge :-) https://gerrit.libreoffice.org/5952
Please test that after your change, drag and drop of a *registered* database still works. I think it will not. Instead of replacing rDescriptor[svx::daDataSource] >>= sDBName; by rDescriptor[svx::daDatabaseLocation] >>= sDBName; try sDBName = rDescriptor.getDataSource(); I think this will work in both cases.
(In reply to comment #13) > Please test that after your change, drag and drop of a *registered* database > still works. I think it will not. > > Instead of replacing > rDescriptor[svx::daDataSource] >>= sDBName; > > by > rDescriptor[svx::daDatabaseLocation] >>= sDBName; > > try > sDBName = rDescriptor.getDataSource(); > > I think this will work in both cases. You're absolutely right, I'm gonna try to find a way for rDescriptor[svx::daDataSource] be filled each time.
I haven't find another way to fill for this so I just used your patch which works perfectly. I've updated the gerrit tracker (see https://gerrit.libreoffice.org/#/c/5952/).
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f499acb2af1d879c776987bdc2366acb5d5964e6 fdo#69091: Copying data from Base-table to Calc by drag and drop The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien, nice collaboration on this one. Thanks!
(In reply to comment #17) > Julien, nice collaboration on this one. Thanks! Thank you but I just retrieved some bts. You're the one who really did it Lionel!:-)
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=22909e644827e6d5bc98b64d581c0616ffb5483c&h=libreoffice-4-1 fdo#69091: Copying data from Base-table to Calc by drag and drop It will be available in LibreOffice 4.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4deb3ec0d5d94a36b3941176b30e662184d2297a&h=libreoffice-4-0 fdo#69091: Copying data from Base-table to Calc by drag and drop It will be available in LibreOffice 4.0.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 52214 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]