1) Open an ODB file 2) Open an ODS file, go to an empty sheet 3) drag'n drop a table from the base window to the Calc sheet This creates a data range which is linked to the database table. In calc, menu Data / Define Range / Options. Note that the "Source" looks like: file:///c:/path/to/foo.odb/tablename In calc, menu Data / Refresh range. Works. 4) Save ODS file. 5) Close ODS file. 6) Reopen ODS file. 7) menu Data / Refresh range Expected result: works Actual result: Unable to establsh connection Note: menu Data / Define Range / Options the "Source" now looks like: /tablename that is, it has lost the path to the odb file. This is confirmed in the actual XML, where content.xml contains something like: <table:database-ranges> <table:database-range table:name="Import1" table:target-range-address="Sheet3.A1:Sheet3.H1319"> <table:database-source-table table:database-table-name="tablename"> </table:database-source-table> </table:database-range> </table:database-ranges> Note the missing "table:database-name" attribute. By contrast, if one drag'n drops from the "Data Sources" calc window (which displays *registered* databases), then it works correctly and the content.xml contains something like: <table:database-ranges> <table:database-range table:name="Import1" table:target-range-address="Sheet3.A1:Sheet3.H1319"> <table:database-source-table table:database-name="foo" table:database-table-name="tablename"> </table:database-source-table> </table:database-range> </table:database-ranges>
Reproduced. Dragging the table like that seems to be a new feature as it is not possible in 4.3. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: 6b65a0e83c4798f117be61af91dbaebdc85e94b7 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-21_03:41:08 Locale: fi-FI (fi_FI)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
(In reply to Buovjaga from comment #1) > Reproduced. > > Dragging the table like that seems to be a new feature as it is not possible > in 4.3. > > Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ > Build ID: 6b65a0e83c4798f117be61af91dbaebdc85e94b7 > CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; > TinderBox: Win-x86@39, Branch:master, Time: 2016-01-21_03:41:08 > Locale: fi-FI (fi_FI) It was a feature since version 2.0 (support for d&d from one top level window to another or from the beamer window to the sheet for Tables, Views and QueryDefinitions) IIRC. And it is broken with 6.1 beta. Just gave it a try, there was a similar issue opened for mail merge recently, similar behavior of not storing the name properly. The Calc files I just this with, when explicitly given the update range generates the error: The interface XQueriesSupplier is not available.
and did check file contents xml, with exact situation was described in the first comment. The database-name property is not included in the database-range entry.
Dear Paulo Martins, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is no longer present in latest Linux versions. I tested in Linux with: Version: 6.4.7.2 Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kf5; Locale: es-ES (es_ES.UTF-8); UI-Language: en-US Calc: threaded Version: 7.1.0.1 Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kf5 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded A new related bag has arisen in version 7.1.0.1. I will file a new bag report.
(In reply to Pinco Pallino from comment #6) > This bug is no longer present in latest Linux versions. Just to confirm, as this was not tested on Linux in the past, you saw the bug on Linux yourself in some older version?
Dear Buovjaga, no, I newer had this bug because I newer used the feature before. I came across it before issuing Bug 139447 when searching for possible duplicates. I saw the message asking people to test if this bug still existed in newer versions so I tested it and reported the result. I hope I did not cause any problem. I take this opportunity to wish you a Happy New Year.
Ok, let's set back to new until someone can test on Windows to confirm it's gone.
Ok I tested on Win 10 and it works. I noticed the "Source" is now shown as a relative path and not absolute like in Paulo's original description. Version: 7.2.0.0.alpha0+ (x64) Build ID: 57a59ad02d2e5e89724c0d2e60cf6e7d99fba005 CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded
still an issue with drag n drop a query in Base to Calc with mariadb database. In this case the path to the database is lost when the Calc file is closed and reopened. Calc still doesn't save the path to the database at closing as already mentioned by Paulo Martins in 2016. When reopening the calc file after saving and trying to refresh range, the following message appears: "XQueriesSupplier interface not available. at /home/buildslave/source/libo-core/dbaccess/source/core/api/RowSet.cxx:2348" the source file only indicate the query: i.e /query1 without full path to database as indicated before saving file on Calc. Only solution found so far is to reopen Base database en redrag n drop the Query. With copy n paste method there is no link at all with the database anymore Works fine with pivot table but less comfortable to work with data in Calc Same issue dragging and dropping a table. Tested with same result on: Linux mint 21.3, LO 24.2.7.2 and LO 24.8.3 Windows Server 2019 Standard 10.0.17763 Build 17763, LO 24.2.7.2 Let me know if anyone has a solution or if more details are needed, best regards and thanks to all Libreoffice developers