<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Creating workbook to workbook links no longer simple." href="https://bugs.documentfoundation.org/show_bug.cgi?id=124461#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Creating workbook to workbook links no longer simple." href="https://bugs.documentfoundation.org/show_bug.cgi?id=124461">bug 124461</a> from <a class="email" href="mailto:bob@telpro.co.za" title="Bob <bob@telpro.co.za>"> Bob</a> <pre>Hi I have reset my profile, to factory defaults, and the final error of slow loading has not improved, if anything seems to have got worse. I have not checked the ODS file functionality,as I would need to now recreate these file. *(see Note Below) Ie having the source files as ODS and OTS, instead of XLSX and XLTX. Libra sits for ever after "enable external content". As this template and the relevant source files sit on a cloud service, I had asked several users to test the app to indicate failures or any issues. The data returned was that MS 7 & 8 had issues with referencing the source files. The Echo to Screen, would indicate that LIBRA could not find '"Drive", "Path", "File name" ' The URL echoed was pointing in the right location and had the right file name, but it still complained the file did not exist, the echo and the actual URL handed to the kernel, must be different. On these users I had them change their working directory default to the templates directory which is part of the directory tree, ie it shares the same root. (Probably just pointing to the root of the tree would have been sufficient,(this just a guess), I can get these users to try that. On win 10 this problem does not seem to exist, you can leave the default working directory untouched and Libra discovers the root. The workaround I discovered is therefore. 1. Use source files as XLSX. This solved the issue of ODS files returning #REF or #VALUE after being closed and the template fired up and asking the source files for data. 2. The only issue now is a time issue. Had to advise users to use Excel until we can discover what is causing this very slow loading of the template file. EXCel 3 to 8 seconds, Libra 20 or more minutes. An aside, I did discover a strange behavior with COUNTIF. Using IF(COUNTIF(Range, condition,T,F), fails with EXCEL if the RANGE is external to the template file, and the external file is closed. Returns #VALUE and only way is to open source file. The only way to get this to work in EXCEL is to use a negative check, IF(ISERROR(Match,Criterion,Range),T,F) Here EXCEL returns the correct result, even if the source file for the range is external and the file is closed. Checked this with LIBRA this morning ad she does not have a problem using Countif to check external files, of IF(ISERROR(MATCH) Feather in your cap. * XCEL 2016 does not like files it created(XLSX), saved by LIBRA, as it reports the file needs repairing. (I do believe this has to do with some very nice features in LIBRA, that are not available in XCEL. Sort of validation data, dynamic formatting in formulae etc) Just before starting this mail I had asked LIBRA to open the template file, XLTX, on a development computer it must now be 30 minutes and still she shows updating external links and the progress bar sits at 33% Have a beautiful day Bob</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>