Bug 97123 - data range created by drag'n drop from base window loses database name on save
Summary: data range created by drag'n drop from base window loses database name on save
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Cell-Reference
  Show dependency tree / graph
 
Reported: 2016-01-14 08:38 UTC by Paulo Martins
Modified: 2021-01-07 18:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paulo Martins 2016-01-14 08:38:31 UTC 
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>
Comment 1 Buovjaga 2016-01-21 12:09:51 UTC 
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)
Comment 2 QA Administrators 2017-03-06 14:31:00 UTC Comment hidden (obsolete)
Comment 3 Drew Jensen 2018-06-07 16:16:58 UTC 
(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.
Comment 4 Drew Jensen 2018-06-07 16:20:45 UTC 
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.
Comment 5 QA Administrators 2019-06-08 02:52:50 UTC Comment hidden (obsolete)
Comment 6 Pinco Pallino 2021-01-06 11:51:26 UTC 
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.
Comment 7 Buovjaga 2021-01-06 11:59:34 UTC 
(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?
Comment 8 Pinco Pallino 2021-01-07 10:58:36 UTC 
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.
Comment 9 Buovjaga 2021-01-07 11:12:02 UTC 
Ok, let's set back to new until someone can test on Windows to confirm it's gone.
Comment 10 Buovjaga 2021-01-07 18:31:10 UTC 
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