The limit of rows for xls is 65536, verify you haven't data neither format beyond that.

(In reply to m.a.riosv from comment #1)
> The limit of rows for xls is 65536, verify you haven't data neither format
> beyond that.

Impossible!
The file contains 3 sheets,  respectively of 24, 215, 291 rows.
I have xls files much stronger without that problem.
I think 65536 is the limit for MSExcel too, but never I had that problem.

What about the substantial difference between xls size and the others?

The different size I think is in relation with the matter that ods+xlsx are compressed files while xls not.

Sorry @ gmarco, but without access to the file, doesn't seem too easy verify the issue. 

Can you attach the file after clear any information that can't be public.

(In reply to m.a.riosv from comment #3)
> Can you attach the file after clear any information that can't be public.

Sorry, but unfortunately opening/closing that file the problem no longer occurs.
That file is the same for which I received the warning after the previous save, and apparently is intact, no missing rows.
The fact remaining certain, documented, is that the warning had appeared: why remain a mystery?

But don't attach the xls, the needed file is ods that when saved shows the issue.

(In reply to m.a.riosv from comment #5)
> But don't attach the xls, the needed file is ods that when saved shows the
> issue.

I think unusefull to attach anything, the file was xls, had already been modified and resaved from Calc as xls, on the last occasion, after further changes, after saving again as xls, Calc displayed the warning in question.
Now, reopening and resaving that file, the probem do not recurs any more.
Nevertheless, the file is apparently intact without missing rows.

Then there is nothing to reproduce and verify.

(In reply to m.a.riosv from comment #7)
> Then there is nothing to reproduce and verify.

Hi, just tonight, changing again the xls file, the problem still occurred.
I wish to point that:
- the message appears after having completed the save (Save As)
- if I do not exit the file and try to save it again with a different name, the warning is repeated
- but if I exit the file, reopen it and resave it (Save As) the warning does no more displays.

Now I ask you: the problem exists, it is regrettably recurring but unfortunately intermittent: do you want the file anyway?

Created attachment 116681 [details]
xls spreadsheet

GOAL !!!
I managed to find a way to reproduce repeatedly the error.
The attached file named "SAVE_AS_test.xls" is the sample base.
Instructions:
- open the file (is quite complex but you should not have the need to investigate the contents or on the formulas)
- in the sheet named "scalare" select rows 1:10
- from Menu select "Insert->Rows"
- now you can also Undo, so the file is again alike when just opened
- from File select "Save As" saving with a new name (eg "SAVE_AS_testXXX.xls")
- after the saving end you should get displayed the warning (doing the above I get it repetitively)

Let me know.

Following steps in comment#10 I can't reproduce the issue.

Please try resetting user profile, sometimes solves strange issues.

https://wiki.documentfoundation.org/UserProfile

(In reply to m.a.riosv from comment #11)
> Following steps in comment#10 I can't reproduce the issue.
> 
> Please try resetting user profile, sometimes solves strange issues.
> 
> https://wiki.documentfoundation.org/UserProfile

Sorry, I've resetted my user profile but nothing changed.
I attach here the zipped user folder (just resetted without any change) for your investigation.
Remember that the problem happens only if the Save As is .xls, and this also creating the file as .ods, opening it and reSaving As .xls

Created attachment 116690 [details]
zipped user profile

@gmarco @m.a.riosv
reproducible as in comment 10 under Win8.1 x64 using LibO 4.4.3.2
please tell which is the O/S you tested.

status NEW. edited summary notes.

(In reply to tommy27 from comment #14)
> @gmarco @m.a.riosv
> reproducible as in comment 10 under Win8.1 x64 using LibO 4.4.3.2
> please tell which is the O/S you tested.
> 
> status NEW. edited summary notes.

HI,
I too am working under Win8.1 x64 using LibO 4.4.3.2

warning is not present in LibO 4.2.7.2 and is present in 4.3.0.4 hence a 4.3.x regression that needs bibisecting

issue also persists in today's 5.1.0.0 daily build

(In reply to tommy27 from comment #16)
> warning is not present in LibO 4.2.7.2 and is present in 4.3.0.4 hence a
> 4.3.x regression that needs bibisecting
> 
> issue also persists in today's 5.1.0.0 daily build

Tommy, fine work, thanks.
But a curiosity: which neologism is bibisecting?
the verb does not exist, what does it mean?

(In reply to gmarco from comment #17)
> 
> But a curiosity: which neologism is bibisecting?
> the verb does not exist, what does it mean?

it's a method to identify the committ which caused a regression.
more infos here: https://wiki.documentfoundation.org/QA/Bibisect

Definitely Windows only. Can't repro:

Bodhi Moksha
Version: 5.2.0.0.alpha0+
Build ID: 5df326438fd3a5613a52b4de1935426911ff1301

I don't think that this is bibisectable as the Windows bibisect package doesn't go back this far. See https://wiki.documentfoundation.org/QA/Bibisect/Windows

This regression was introduced before branch 4.4, thus it can't be bibisected with the current bibisect repositories. Changing keyword 'notBibisectable' to 'preBibisect'

Still in LO 5.2.3.3 Win10.
Tha same warning as in the past, both saving as .xls and .ods

Why this bug is assigned to myself?

Because you do it, take a look to the history, top-right.

(In reply to m.a.riosv from comment #24)
> Because you do it, take a look to the history, top-right.

OK, thanks, but I do not know how and why this happened.
I can not fix the bug, so I think corrected unassign myself.

Sorry but the post is 3 years old and since then I do not use that file anymore, downloading the one attached in 2015 does not reflect the problem anymore.
But many conditions have changed: libo was v.4.3 and Win 8.1, now I have v.5.4 and Win 10, then a "guilty" was, now it will remain "mysterious and unpunished" and so "worksforme".
Greetings.

Unfortunately I said all that too soon, the problem is still such (I had forgotten to save by Save As).
Following the steps as per comment 10 the warning occurs both in LO5442 and in LO 5451 (see the new screenshots), the only difference is the text, a mix EN-IT, and it occurs also opening/saving an ods file as said per comment 12.

Created attachment 140119 [details]
screenshot

Created attachment 140120 [details]
screenshot

Further information: same warning also in LODev Version: 6.1.0.0.alpha0 + (x64)

Putting back to NEW...

Warning is already present in 4.2.0.0alpha1 (first commit of win32-4.3 bibisect repo)

What's more, the warning is present already in 3.5.0 and 3.3.0!

What's EVEN more is that the warning is also present on Linux!!@@

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 9030ffb1a1b282eb2c6d1773930b0de0d42df447
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 13 April 2019

Repeating the case as per comment #10 nothing has changed (LO 7.1.1.2): see attached scr.shot.

Created attachment 171188 [details]
last screenshot

YES, I confirm that repeating the case as per comment #10 nothing has changed (LO 7.4.6.2)

(In reply to gmarco from comment #38)
> YES, I confirm that repeating the case as per comment #10 nothing has
> changed (LO 7.4.6.2)

@gmarco,

I'd like to ask for confirmation of the following test(s).

Test A (as in comment 10):
1. Open attachment 116681 [details] from comment 9.
2. Select rows _headers_ from row 1 to 10.
3. [CTRL]+[+] (> insert full rows)
4. [CTRL]+[Z] (> undo, the _entire_ rows from row 1 to 10 are still selected)
5. Menu File > Save as > testA.xls (> I get the message about too many columns for the xls file format).


Test B (as in comment 10, but with small difference):
1. Open attachment 116681 [details] from comment 9.
2. Select rows _headers_ from row 1 to 10.
3. [CTRL]+[+] (> insert full rows)
4. [CTRL]+[Z] (> undo, the _entire_ rows from row 1 to 10 are still selected)
5. [CTRL]+[HOME] (> no row is selected; only cell A1 has focus)
6. Menu File > Save as > testB.xls

With testA, I get the message about too many columns for the xls file format.

With testB, no such message.

@gmarco, Could you please confirm whether you experience the aforementioned respective behaviors with each of these two tests?

FWIW, I can get an even simpler test.

1. Open attachment 116681 [details] from comment 9.
2. Click on the _header_ for row 1 (> the _entire_ row 1 is selected)
3. Menu File > Save as > testB.xls (the name must change from the original).

With that, the message about too many columns for xls file format is displayed once the file is saved for the first time with a new name.

Note that no real action was performed on the file; only the entire row is selected and a new name is used (in order to trigger the check and thus the message).

When only cell A1 has focus (so, no full row is selected), there is no message.

BTW, the title subject of this report is incorrect. It is _not_ about too many rows, but about too many columns, and the only requirement is to have "too many columns selected by the time the file is saved as xls" in order to trigger the message.

(In reply to ady from comment #40)

Sorry, we don't need any prior attachment either.

1. Open Calc. then.

> 2. Click on the _header_ for row 1 (> the _entire_ row 1 is selected)

3. [CTRL]+[S] as xls.

The rest is of course valid.

> 
> With that, the message about too many columns for xls file format is
> displayed once the file is saved for the first time with a new name.
> 
> Note that no real action was performed on the file; only the entire row is
> selected and a new name is used (in order to trigger the check and thus the
> message).
> 
> When only cell A1 has focus (so, no full row is selected), there is no
> message.
> 
> BTW, the title subject of this report is incorrect. It is _not_ about too
> many rows, but about too many columns, and the only requirement is to have
> "too many columns selected by the time the file is saved as xls" in order to
> trigger the message.

Well, the substance doesn't change and perhaps it becomes more complicated,
selecting only line 1 and saving the file as xls this is the result:
- saving with [CTRL]+[S] everything is OK
- saving with [CTRL]+[Uppercase]+[S] the warning is (translated from IT):
"Be careful when saving the test document:
The document contains more columns than the limit supported in the selected format.
The excess columns have not been saved."
NOTE: IT SAYS columns !

but ...
selecting only column A and saving the file as xls with [CTRL]+[Uppercase]+[S] the warning is:
"Be careful when saving the test document:
The document contains more lines than the limit supported in the selected format.
The excess lines have not been saved."
NOTE: IT SAYS lines !

I confirm that the problem occurs only when saving the file with SAVE AS changing the name and every time after that it is re-saved with SAVE AS changing the name again.

I add:
same problem also opening a new sheet [CTRL]+[N] and copying only the used cells A1:P305 there, then selecting a column or a row and saving it as xls with a different name.

(In reply to gmarco from comment #43)
> I add:
> same problem also opening a new sheet [CTRL]+[N] and copying only the used
> cells A1:P305 there, then selecting a column or a row and saving it as xls
> with a different name.

You don't need to copy anything. When starting Calc with a new (yet to be saved for the first time) spreadsheet, and then selecting entire rows (or entire columns), the first save (as) with a new name will trigger the message.

IOW, by just _selecting_ more rows or more columns than xls supports, the xls filter attempts to save all those selected columns/rows as if all of them were part of the active range, while in fact they are only selected.

The behavior I am describing here is not not present in AOO and was not present in LO 3.3. It is indeed present in LO 4.4. I have not tested versions between them.

Maybe by solving the "selection-only" part of the problem will solve the original problem too, with simpler STR.

ATM most of the 40+ prior comments in this report seem obsolete by now.

... and then?

Just for information, as of today I have no more potentially affected xls files.

(In reply to gmarco from comment #45)
> ... and then?
> 
> Just for information, as of today I have no more potentially affected xls
> files.

One possibility would be to open a new bug report, with the following STR:

1. New Calc.
2. [CTRL]+[A]
3. [CTRL]+[SHIFT]+[S]
4. Use a new/different file name; select the type of file to be 97-2003 XLS; [OK]
5. In the first dialog, confirm the XLS file format (instead of the suggested ODS file format).

Actual result:
There is a warning, either about too many rows or about too many columns not supported by the (XLS) file format.

Expected result:
Avoid either of the 2 possible warnings when it is about selection _only_ and there is no real dependency on columns/rows beyond the XLS limit (i.e. beyond cell IV65536, or R256C65536).


Then this bug 92164 could be set as "See also" of the new one (not as duplicate, just in case, unless QA team decides it is what it should be).

Advantages:
* simple STR,
* covers the 2 possible warnings (i.e. both cases should be solved),
* no need to read 40+ comments (most of them obsolete by now).


Having said that, I would rather have some feedback/comment about this suggestion from someone from the QA team before doing anything of that sort.

(In reply to ady from comment #46)

Following up on my comment 45, as I said, I'm personally no longer affected by the problem (it was from 2015) and you can do what you prefer.