The problem is NOT evident using LibO 3.4.6 (on Mac OS X.6)

I can confirm this with LO 3.6.0.2 RC: XQueriesSupplier not available.
With LO 3.3.4 ist works.
My System: OpenSuSE 32bit-rpm (Linux).
Set the Status to "New" and the Platform to "All".

I have the same problem with LibreOffice 3.5.6.2 
Build ID: e0fbe70-5879838-a0745b0-0cd1158-638b327 on Windows 7 Home Premium.  If I try to drag the query to the spreadsheet, I get the error message.  If I right click the query and choose "copy" and then go to a cell in the spreadsheet and click "paste" then the query will be copied into the spreadsheet.

Adding Lionel to CC - care to take a look ?

Alex

I can confirm this too, even on my home build from master :

Version 3.7.0.0.alpha0+ (Build ID: 27fafb7)



Alex

Do you remember with what version it worked?

Fred says 3.4.6 doesn't have the problem. I can only try on a 3.3.4 version sometime Wednesday.

Alex

(In reply to comment #7)
> Fred says 3.4.6 doesn't have the problem.

Ah yes, missed that.

Tried on a debug build. Get these message on stdout/err:


warn:legacy.osl:22608:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/svx/source/form/dataaccessdescriptor.cxx:368: ODataAccessDescriptor::operator[]: invalid acessor!
warn:legacy.osl:22608:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/connectivity/source/commontools/dbtools.cxx:1791: dbtools::askForParameters XSQLQueryComposer is null!
warn:legacy.osl:22608:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/connectivity/source/commontools/dbtools.cxx:1793: dbtools::askForParameters XConnection is null!


The error message comes from:

dbaccess/source/core/api/RowSet.cxx:2388 function sal_Bool ORowSet::impl_buildActiveCommand_throw()

    switch (m_nCommandType)
    {
        case CommandType::QUERY:
        {
            Reference< XQueriesSupplier >  xQueriesAccess(m_xActiveConnection, UNO_QUERY);
            if (xQueriesAccess.is())
            {
                 (...)
            }
            else
                throw SQLException(DBA_RES(RID_STR_NO_XQUERIESSUPPLIER),*this,::rtl::OUString(),0,Any());


My guess is that m_xActiveConnection is NULL to begin with, which is probably caused by the first warning.

OK, about warn:legacy.osl:22608:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/svx/source/form/dataaccessdescriptor.cxx:368: ODataAccessDescriptor::operator[]: invalid acessor!

_eWhich argument is svx::daDataSource

parent is:

#1  0x00007fffce620243 in ScDBDocFunc::UpdateImport (this=0x7fffffffcdf0, rTarget="Import1", rDescriptor=...)
    at /home/master/src/libreoffice/workdirs/libreoffice-3.6/sc/source/ui/docshell/dbdocfun.cxx:1550
1550	    rDescriptor[svx::daDataSource]  >>= sDBName;


but:

(gdb) print *rDescriptor.m_pImpl
$5 = {
  m_bSetOutOfDate = 1 '\001', 
  m_bSequenceOutOfDate = 0 '\000', 
  m_aValues = std::__debug::map with 3 elements = {
    [svx::daDatabaseLocation] = uno::Any "file:///home/master/src/gestman/soc.odb",
    [svx::daCommandPython Exception <type 'exceptions.UnicodeEncodeError'> 'ascii' codec can't encode character u'\xe9' in position 15: ordinal not in range(128): 
] = ,
    [svx::daCommandType] = uno::Any 1
  }, 
  m_aAsSequence = uno::Sequence of length 3 = {{
      Name = "DatabaseLocation", 
      Handle = 1, 
      Value = uno::Any "file:///home/master/src/gestman/soc.odb", 
      State = com::sun::star::beans::PropertyState_DIRECT_VALUE
    }, {
      Name = "Command", 
      Handle = 4Python Exception <type 'exceptions.UnicodeEncodeError'> 'ascii' codec can't encode character u'\xe9' in position 15: ordinal not in range(128): 
, 
      Value = , 
      State = com::sun::star::beans::PropertyState_DIRECT_VALUE
    }, {
      Name = "CommandType", 
      Handle = 5, 
      Value = uno::Any 1, 
      State = com::sun::star::beans::PropertyState_DIRECT_VALUE
    }}, 
  m_xAsSet = empty uno::Reference
}


In particular, no daDataSource entry.

The code mentioned in previous comment is introduced by:

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



@eike: do you have a clue? Maybe there is a fixup already in dr78 or another cws?

Still a problem with 4.1.2 release
 3ca9241defd7d7a2f10d87586fb32818e76df094 is the first bad commit
commit 3ca9241defd7d7a2f10d87586fb32818e76df094
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Fri Dec 9 00:50:28 2011 +0100

    source-hash-ceb55cd688cebede8cef8408540019fe54528869
    
    commit ceb55cd688cebede8cef8408540019fe54528869
    Author:     Michael Bauer <fios@akerbeltz.org>
    AuthorDate: Mon Nov 28 20:37:54 2011 +0100
    Commit:     Eike Rathke <erack@redhat.com>
    CommitDate: Mon Nov 28 21:09:23 2011 +0100
    
        [gd-GB] partitive vs genitive case month names

:100644 100644 eb0cb2b4ffcbaf6d377cb7c7c93a20f34bbbf004 1b490ce3d8ca956972b88f33f5ef54cba84202a5 M	ccache.log
:100644 100644 9e581569fd6a3cc0da77434438a26c32db7325f3 beff12644fd59c04475e990f67ce1ac0e404d83c M	commitmsg
:100644 100644 b77420584faa300d427a7a71d71df5c3034bd521 836d22c9242e1971da374cbf23c36e1ad8626473 M	dev-install.log
:100644 100644 fc8d3989cd87a8768dea5f9c533cd718d72f5bec a6ae53922a3b0cc49d14e3a7b9c4dfd87be5c4ef M	make.log
:040000 040000 1036a9f7d26b40eec5c3db29eac489ba6ae8a043 d77236f0aa011a248abe7d5eded963e3d73c330a M	opt



# 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
# first bad commit: [3ca9241defd7d7a2f10d87586fb32818e76df094] source-hash-ceb55cd688cebede8cef8408540019fe54528869

(In reply to comment #11)

> # good: [a059dc3aa6f025fcff113c166b081946def03190]
> source-hash-55c5ea43a59e505297fb6fa20b77aaa28f7c67bc
> git bisect good a059dc3aa6f025fcff113c166b081946def03190
> # first bad commit: [3ca9241defd7d7a2f10d87586fb32818e76df094]
> source-hash-ceb55cd688cebede8cef8408540019fe54528869

This is consistent with my findings in comment 10.

> Still a problem with 4.1.2 release

Hmmm... This looks like a DUP of bug 69091; please test again with 4.0.6 or 4.1.3 or master of 17 sep 2013 or later. If reproducible in these versions, reopen.

*** This bug has been marked as a duplicate of bug 69091 ***

Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]