Created attachment 117848 [details] Test showing the broken import functionality When importing a csv file (FILEOPEN) (specifically a "Bulk Export" from FreePBX), it gets all screwed up when it encounters a field with quotation marks. I don't believe this problem happened in 4.xx because I used it all the time and didn't encounter this issue. I've tried unchecking all the various options in the import, and tried changing the character set, always the same result. "The data could not be loaded completely because the maximum number of characters per cell was exceeded." The field that triggers this looks like this: ,"Caller Name" <7145555555>, What happens is the cell looks like this: Caller Name" <7145555555>,all,the,rest,of,the,data including,the,next,rows,everything shows,up,in,this,cell,until,it,encounters,another cell,like that This is a HUGE problem for me, this is the #1 purpose I use Calc for, and I cannot use this until it's fixed. Attached example. All import options are off except: [x]Comma, Text Delimiter is " (double quote). It's not closing the delimiter when it hits the 2nd double quote. Files: test1 - Shows how the bug works as I've described. test2 - Can only attach 1 file, test2 is pasted below: ------------------test2-------------------------------- Name,Phone,CallerID,Miscellaneous test,555555555,5555555555,bla blah blah,"context,menu,priority" test2,543422332,1241232134,still ok...,"help,test,2" Rob,7145555555,"rob test" <7145555555>,this is where it breaks,"cat,goes,4" test3,444412323,444124213,uh oh still broken,"hello,test,5" test4,99999999,99999999,what can i do?,"broken,extension,1" test5,44444444,44444444,here is a text,"context,menu2,1" -------------------end of data----------------------------
Hi @themrrobert, thanks for reporting. I think the issue is with: "rob test" <7145555555> not the whole field is between quotes, while other fields are. It's needed to set up "double quotes" as Text delimiter to import right the last fields of the rows, because they have inner commas, and this field breaks the rule. The row must be: Rob,7145555555,"rob test <7145555555>","cat,goes,4" or Rob,7145555555,rob test <7145555555>,"cat,goes,4" both they work well. But for me not a bug, please if you are not agree, reopen it.
Sorry, concur it is NOTABUG. Also, this did work in ancient builds but that the ,"Caller Name" <<7145555555>, delimited form was correctly handled with any LO builds in the last couple of years. What does format correctly is to remove the Text delimiter " quotes for the field. Or alternatively to place the closing " after the phone number's closing bracket >--or even adding an extra ". Looking back, I see the same behavior described in each prior release: 4.4.4.3 4.3.6.2 4.2.6.3 4.1.5.3 4.0.6.2 3.6.7.2 (2013-07-09) That mixed use of " and > in a comma separated field wss handled correctly (by chance?) through earlier builds: 3.5.7.2 (2012-10-03) 3.4.6.2
(In reply to V Stuart Foote from comment #2) s/form was correctly/form was incorrectly/