Bug 61587 - : Link to External Data no longer works in 4.0.0.3 (was working in 3.6.4.3
Summary: : Link to External Data no longer works in 4.0.0.3 (was working in 3.6.4.3
Status: RESOLVED DUPLICATE of bug 63407
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.1.2 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-28 06:22 UTC by KSN
Modified: 2013-11-19 15:40 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Source and Target files for testing (13.67 KB, application/zip)
2013-03-03 10:41 UTC, KSN
Details
Re-sending the attachment referred above (13.67 KB, application/zip)
2013-03-03 10:57 UTC, KSN
Details

Note You need to log in before you can comment on or make changes to this bug.
Description KSN 2013-02-28 06:22:53 UTC
Problem description: 
Inserting a link to a Range in an External Workbook returns the text "The link could not be updated."
Steps to reproduce:
1. In one workbook, say "ABC.ods", select a range and give it a name, say "ImportRange"
2. Save this workbook
3. Open another workbook.
4. Click on Insert-->Link to External Data, Browse to the workbook ABC.ods, Select the range name "ImportRange" and Click OK


Current behavior:
The text "The link could not be updated." is displayed
Expected behavior:
The named range in the external workbook should appear.
This behaviour works fine in 3.6.4.3 (Debian)
              
Operating System: Debian
Version: 4.0.0.3 release
Comment 1 Markus Mohrhard 2013-02-28 06:40:58 UTC
Can you please retest with 4.0.1? I fixed several bugs around cached value import and there was one for links to external data.
Comment 2 KSN 2013-02-28 09:28:14 UTC
I installed and tried this with Version 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659)

The problem of inserting an link to a named range in an external file still exists.  The returned text is the same as in the problem definition.

Regards
KS
Comment 3 Markus Mohrhard 2013-03-03 06:46:17 UTC
Ok. Can you please attach a simple test document?

I'll have a look at it for 4.0.2.1
Comment 4 KSN 2013-03-03 10:41:58 UTC
Created attachment 75823 [details]
Source and Target files for testing
Comment 5 KSN 2013-03-03 10:50:02 UTC
Hi Markus

For some reason (it's also the first time that I am submitting a file as an attachment), my comments did not get uploaded.

The zip file contains two files "Source.ods" and "Target.ods".  The file "Source.ods" contains the months Jan to Dec in cells A1 to A12 and has the range name "Months".

The file "Target.ods", in range A1 contains a link to the range name "Months" in file "Source.ods", but currently shows only the text "The link could not be updated."  Opening the file "Target.ods", you are asked if the links are to be updated.  Nothing happens when you answer with a "Yes".  What is expected that the values in the range "Months" should be populated in A1 to A12.

Hope this helps and thanks for your help in trying to fix this issue, since linking of worksheets is a function that many experienced users of spreadsheets use.

Regards
KSN
Comment 6 KSN 2013-03-03 10:57:02 UTC
Created attachment 75824 [details]
Re-sending the attachment referred above
Comment 7 Nosredna Aievuog 2013-03-07 02:03:15 UTC
Hi everybody,

I had a similar problem only in some computers, and what i found was:
DOES NOT HAPPEN
- This problem DOES NOT happens when the computer runs v3.4.5 and v3.4.1
- DOES NOT happens anymore when we save the same file as ODS

DOES HAPPEN
- The problem DOES HAPPENS when the computer runs v3.6.4.3, v3.6.5, v4.0.0.3 and v4.0.1.2
- When the path have a "# (sharp/hashtag symbol)" and the file is saved as XLS, the "#" is represented by "%23" and works properly right after we confirm the formula, but when we close the file and then reopen it, the "%23" becomes "%2523". Thats why we get the message: "The link could not be updated".

If we take out the "#" of the path of the file, and edit the formulas, the problem is solved.

If we just edit the formula and take out only the "25" from "%2523" it works until close the file, whe we reopen it, the "%23" becomes "%2523" again.

Exemple creating a link to:
='file:///C:/Users/ana/Desktop/#FOLDER/FILEXLS.xls'#$Sheet1.A1
becomes
='file:///C:/Users/ana/Desktop/%23FOLDER/FILEXLS.xls'#$Sheet1.A1
after close and reopen file becomes:
='file:///C:/Users/ana/Desktop/%2523FOLDER/FILEXLS.xls'#$Sheet1.A1

Hope it can help, for further explanation just let me know
Best Regards
Anderson
Comment 8 Derek Pugsley 2013-03-09 12:57:34 UTC
I think the problem may lie in the following code from FindExtRange() in code file arealink.cxx:

version 3.6.5.2
const ScRangeData* p = pNames->findByUpperName(ScGlobal::pCharClass->uppercase(rAreaName));

version 4.0.1.2
const ScRangeData* p = pNames->findByUpperName(rAreaName);

As you can see in the latest version the search for a range name is successful only if the name is in uppercase.

To test this I created a file called data.ods with a data range called test.
When I opened another workbook and tried to create a Link to External Data the text "The link could not be updated." was displayed.
I then reopened the data.ods file and changed the range name to TEST.  The Link to External Data request then worked and the data was imported.
Comment 9 KSN 2013-03-10 01:04:00 UTC
Hi

I agree with Derek's analysis.  In the "Source.ods: file that I had submitted earlier (Source.ods), I deleted the range "Months" and gave the same range the name "MONTHS"

In the "Target.ods", I first removed the existing link, since it was referring to "Months" in the "Source.ods" file.  Inserting a new link to the range "MONTHS" in the file "Source.ods", works and brings in the data.

Thanks very much, Derek.

Hope this fix can be done quickly?

KSN
Comment 10 Joel Madero 2013-04-15 00:01:47 UTC
Although this is an earlier report - it's a dupe of a bug that has already had a bibisect. 

Marking as such. Please put any additional comments on the other bug. Thanks!

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