Created attachment 50612 [details] A sparsely populated CSV file with 9 rows and 2,455 columns On LibO master built as of 24 Aug, opening the attached file loses columns. This bug report is either of: 1. an incorrect error message 2. a request to make the number of cells (columns/rows) unlimited As 2 is potentially under way with ixion and a long-term move away from cell-based treatment of spreadsheets, my guess is that 1 is the more correct characterization of the problem. Therefore, I suggest this is a trivial problem, and the steps to reproduce: 1. Open attached "lp_matrix_example.csv". 2. Select "Separated by" and choose Comma and the double quote as the "Text delimiter". 3. Observe the dialog, which says "The maximum number of rows has been exceeded. Excess rows were not imported!" This file has 2,455 columns, so that is potentially expected, but it only has 9 rows. Thus, at the very least, the dialog box needs to updated with "columns" instead of rows.
Reported effect is visible with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" The message problem might be related to a.m. OOo bug. OOo 3.3 shows the same nonsense message. I did not find a GNUMERIC setting for comma separation. @Kevin Hunter We only can handle 1 prolbem per bug report, so here we only will investigate your "1. an incorrect error message" For further problems further reports will have to be submitted. I doubt that there is an interest to allow unlimited No of columns/rows. But I believe your example should have been opened correctly, IMHO LibO allows more than 6000 columns.
Not master specific, see Comment 1
Chalking it up to my learning curve, it turns out this is as simple as a #define in sc/inc/address.hxx and a few handling cleanups. The current supported column size is (apparently) 1024. As I'm now running a test build with a good bit more than that, for the time being (perhaps until ixion is in major use), it would seem that 1024 is good decision for performance reasons. (Lots of seemingly easy operations take for...ev...er.) Thus, I don't know where I got it in my head that LO supports X number of columns (maybe I confused it with rows?), but it would seem it does not. However, this bug report is still valid (and I don't yet know how to fix it): the /message/ needs to be updated to jive with actual problem.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
As built with LibreOffice branch 3.5, post Beta2: $ git log -1 --format=oneline 7dfc54c7337f77be8e258a218df741c330904f73 support libebook-1.2.so.12 (evolution 3.2) I believe this to still be an issue, but as the submitter, I won't mark it as NEW. It's a (very) minor one, likely not to be hit by most folks who work entirely within LO rather than at an interface between programs, and it is /merely/ an incorrect message, but it should be simple to fix. At least in my case, it would have been helpful to note in the message exactly how many columns /are/ supported.
It pays to be concise in bug reports ... *** This bug has been marked as a duplicate of bug 43911 ***