Description: I have only recently upgraded to this current release. The formula identified above has functioned as expected for up to 3500 cells on almost 500 iterations. Taking a simple growth factor of half of the 3500 cells, that's 875,000 success units. It can't be my fault. When upgrading to the current release, the user profile was cleared and reset. I omitted to set the parameter for formulae to adjust to their new sort location. Clearly, this parameter is required as eXcel seems unable to "follow the plot" so we have to either dumb it down for compatibility or set the parameter to allow us to utilise the inherent superiority of LO. When I first processed a sheet with the latest version which had originally been saved under the older version with the "follow me" enabled, I hadn't noticed the parameter wasn't set nor the impact upon the results - and saved the file. This implied that "follow me" was also not correctly saved with the latest file. Subsequently, processing another file I realised the sort was "screwed" and set the parameter to "follow me". Today, I updated the sheet and the result was clearly incorrect as a statistical improbability had occurred - I thought it was unusual last week but not exceptionally so. Upon inspection of the attached screen dumps you can see that the earlier saved formula returns the correct result but the later saved identical formula returns pure gibberish. I'm sure you can figure the formula but for the record, it just tests the string to establish the existence of the source value and flags it with a "1". If you can find a correct match in the later sheet's formulae then I'm seriously deluded. Fortunately, It only recently "bombed" so hopefully, I will be able to rebuild the analysis by simply reprocessing a couple of weeks' data in a previously saved version with the parameter corrected in the current software. "Hopefully" being the operative word. If the later version still can't deal with it then the problem is even greater than imagined as I can't reprocess 7 years of data. I would be forced to "fall back" to an earlier version and then reprocess the data. It is a simple matter to provide the original sheets in their full form if that is of assistance in analysing and comparing the internal structures. Also, as the autofilters cannot sort according to any user-defined "sort sheets" I have built a little index into column M which assigns a numerical value to the user sort criteria and this value is extracted from a simple VLOOKUP. I sort and select the analysis on these requisite values in column M Steps to Reproduce: As described, I saved a sheet with an older version and formulae following parameter set and reopened it in a later version without setting that parameter. Having saved the updated sheet it is now apparent that a tried and tested function no longer functions. It's impossible for a user to define whether it's a sorting error, a function error, a file save error or a user profile error - but a profile error would be a failure of LO to utilise the amended profile on a later sheet. 2. 3. Actual Results: Incorrect value assigned Expected Results: Correct value to be assigned Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 174771 [details] Screen dump
Sorry but could you just describe clearly in a few lines the pb? I mean, just take a look at the number of bugs here:https://bugs.documentfoundation.org/buglist.cgi?cmdtype=runnamed&list_id=1349353&namedcmd=all_global The template of bugtracker: "Steps to reproduce", Actual Results, ... are there for this. See https://wiki.documentfoundation.org/QA/BugReport from "Good Reports" paragraph. Some examples of clear and short bugtrackers are given like https://bugs.documentfoundation.org/show_bug.cgi?id=85004 Anyway, in order to reproduce the pb, please attach an example file. Without this, I don't think it'll be easy to reproduce this and so to debug it.
Created attachment 174772 [details] Version 6 File
Created attachment 174773 [details] Version 7 Save
(In reply to Julien Nabet from comment #2) > Anyway, in order to reproduce the pb, please attach an example file. Without > this, I don't think it'll be easy to reproduce this and so to debug it. (In reply to Julien Nabet from comment #2) > > > Anyway, in order to reproduce the pb, please attach an example file. Without > this, I don't think it'll be easy to reproduce this and so to debug it. What's more important is to fully understand it. The circumstances are defined in the original text and also the difficulty with which to categorise it. 2 files attached The screen images refer to sheet 1 on either file. Simply place your cursor on the indicated cell, absorb the relevant circumstances of the new manifestation and perhaps then you will understand why it's so difficult to describe the error and why this report is nothing like the 27 open bugs already reported by me. Personally, I would have assumed that looking at the images and understanding the conflicting interpretation of the previously highly successful function would have been sufficient to not patronise a user. Certainly, identifying the difference between the correct and incorrect interpretation of the same function when a simple picture admirably demonstrates the issue is not rocket science - would you disagree?
Having uploaded the files I notice that the earlier file v.6 is larger in size than the v.7 version but contains less data. Is that significant?
I open the two completely different attachments. The "Version 6 Save" has plain "4" in Stats.M4, while "Version 7 Save" has "5" there. That cell is used in the formula in 'Version 7 Save'.AllHits.E1; but 'Version 6 Save'.AllHits.E1 refers to Stats.N4, which is a formula returning a string "04". The AllHits.E1 is used in AllHits.E6... how could one compare?
On version 6 file: - I clicked on AllHits sheet (so sheet number 1) - E1 contains "=Stats.N$4" and displays "04" - C6 contains "05 07 12 19 26" - I clicked on E6, "=IFERROR(IF(SEARCH(E$1;$C6)<1;"";1);"")", displays nothing => nothing wrong here, there's no "04" in the string On version 7 file: - I clicked on AllHits sheet (so sheet number 1) - E1 contains "=Stats.M$4" and displays "5" - C6 contains "05 07 12 19 26" - I clicked on E6, "=IFERROR(IF(SEARCH(E$1;$C6)<1;"";1);"")", displays 1 => nothing wrong here, the 5 is in the string. About the rest of your comment, if just asking for clear and simple steps to reproduce the pb is correspond to patronize, sorry for you.
(In reply to Mike Kaganski from comment #7) > I open the two completely different attachments. The "Version 6 Save" has > plain "4" in Stats.M4, while "Version 7 Save" has "5" there. That cell is > used in the formula in 'Version 7 Save'.AllHits.E1; but 'Version 6 > Save'.AllHits.E1 refers to Stats.N4, which is a formula returning a string > "04". The AllHits.E1 is used in AllHits.E6... how could one compare? They're a three week old version that worked fine with "formulae follow me" applied and a today version that fails and the only difference I can identify is that I originally forgot to set "follow me" with v.7 and then realised my omission and subsequently set it . If you look, even though the underlying data is different, the test is still to discover whether the "zero padded number" in the absolute source cell appears anywhere in the relative string of the comparison cell. It Doesn't Look at the two images, the numbers on that sheet - regardless of their original source are not found in the target string for which they are compared. In the v.6 sheet the object cell returns a null value but in v.7 it claims to have found the string and returns 1. The problem being, the string doesn't match in v.7 but returns a positive test value.
(In reply to Mike Kaganski from comment #7) > I open the two completely different attachments. The "Version 6 Save" has > plain "4" in Stats.M4, while "Version 7 Save" has "5" there. That cell is > used in the formula in 'Version 7 Save'.AllHits.E1; but 'Version 6 > Save'.AllHits.E1 refers to Stats.N4, which is a formula returning a string > "04". The AllHits.E1 is used in AllHits.E6... how could one compare? They're a three week old version that worked fine with "formulae follow me" applied and a today version that fails and the only differnce I can identify is that I originally forgot to set "follow me" with v.7 and then realised my omission and subsequently set it . If you look, even though the underlying data is different, the test is still to discover whether the "zero padded number" in the absolute source cell appears anywhere in the relative string of the comparison cell. It Doesn't
(In reply to Julien Nabet from comment #2) > Sorry but could you just describe clearly in a few lines the pb? > I mean, just take a look at the number of bugs > here:https://bugs.documentfoundation.org/buglist. > cgi?cmdtype=runnamed&list_id=1349353&namedcmd=all_global > > The template of bugtracker: > "Steps to reproduce", Actual Results, ... are there for this. > See https://wiki.documentfoundation.org/QA/BugReport from "Good Reports" > paragraph. > Some examples of clear and short bugtrackers are given like > https://bugs.documentfoundation.org/show_bug.cgi?id=85004 > > Anyway, in order to reproduce the pb, please attach an example file. Without > this, I don't think it'll be easy to reproduce this and so to debug it. If you can't comprehend how this could be deemed a little OTT then you're the one deserving of sympathy. It even appears that with the benefit of 2 sheets and two images depicting how a simple test to identify whether the source zero-padded number appears in the string with which it is being compared returns a false positive in the v.7 sheet then perhaps you should stick your day job. Would you prefer to press the reset button?
(In reply to Colin from comment #10) > (In reply to Mike Kaganski from comment #7) > > I open the two completely different attachments. The "Version 6 Save" has > > plain "4" in Stats.M4, while "Version 7 Save" has "5" there. That cell is > > used in the formula in 'Version 7 Save'.AllHits.E1; but 'Version 6 > > Save'.AllHits.E1 refers to Stats.N4, which is a formula returning a string > > "04". The AllHits.E1 is used in AllHits.E6... how could one compare? > > They're a three week old version that worked fine with "formulae follow me" > applied and a today version that fails and the only differnce I can identify > is that I originally forgot to set "follow me" with v.7 and then realised my > omission and subsequently set it . > If you look, even though the underlying data is different, the test is still > to discover whether the "zero padded number" in the absolute source cell > appears anywhere in the relative string of the comparison cell. > It Doesn't Sorry Mike, I just fully absorbed what you said. The zero-padding that has existed since 2013 has disappeared from the sheet. Hence say a "9" is also being returned within a "29". Will you make it NOTABUG or should I?
(In reply to Julien Nabet from comment #8) > On version 6 file: Time for umble pie. A zero-padding test that has existed since the sheet was built almost 500 weeks ago has disappeared. I need to check if that was a downside of the upgrade. In any event, my apologies for escalating what I perceived as a scolding. Pause, Reset, Rewind?