[Solved] Cannot load Excel file created with FPSpreadsheet lazarus / 49-FPSpreadsheet ---------------------------------------------------------------------- Edson · 2024-08-27 15:25 Hi, I have a code to create an Excel from a DBF that basically write values to cells using TsWorksheet.WriteUTF8Text() and creates the Excel file using TsWorkbook.WriteToFile('myExcelFyle.xlsx', sfOOXML). I'm using xlsxooxml unit. It run without errors in Lazarus but when I try to open the file it Excel I get something like "A problem was found in the content of . Do you want we try to get the content?" The table I tried to save has 5153 rows and 20 columns. When I run the same code in a table of 1217 rows and 16 columns it works OK and I can open the Excel normally. I've read some post about the same problem but they are for old versions. I'm using Lazarus 2.2.6 an FPC 3.2.2 running on Windows 10. I get the FPSpreadsheet using the OPM. The version registered is 1.14.0.0. My Excel version is: Microsoft® Excel® para Microsoft 365 MSO (versión 2407 compilación 16.0.17830.20166) de 64 bits. Thanks in advance. ---------------------------------------------------------------------- wp · 2024-08-27 17:31 This issue cannot be handled without further information. Provide a simple project which produces that faulty file (only .pas, .lfm, .lpr, .lpi and .dbf files) ---------------------------------------------------------------------- Edson · 2024-08-27 23:07 Hi. I attach a simplified version of my project. ---------------------------------------------------------------------- wp · 2024-08-28 07:30 My Excel 2016 does not report any error reading the two files created by FPS1.16 (OPM) on Laz2.2.6 (both 32bit and 64bit), Win 11. Could you upload the defective file to some cloud and post the link so that i can have a look? ---------------------------------------------------------------------- jcmontherock · 2024-08-28 10:16 My Excel 2019 does not report any error, as well. ---------------------------------------------------------------------- Edson · 2024-08-28 15:04 Quote from: wp on August 28, 2024, 09:30:48 amMy Excel 2016 does not report any error reading the two files created by FPS1.16 (OPM) on Laz2.2.6 (both 32bit and 64bit), Win 11. Could you upload the defective file to some cloud and post the link so that i can have a look? Hi. These are my Excel files generated. The problem is in the bigger one. https://aprendo123.com/principal/TestFailExcel.zip EDIT: I realized the problematic Worksheet has 91 columns. Maybe that's originating the error on create the Excel. ---------------------------------------------------------------------- wp · 2024-08-28 18:47 Trying to load the Almacen.xlsx into Excel2016 I get an xml error in the "sharedstrings.xml" file at offset 563101 ("invalid xml character"). The string around this offset is 'TABLERO ASADO  TABLEREO TD-SR1 '#$85#$85'TD-SR5'. Looks like an ANSI codepage-to-UTF8 conversion problem because Dbf is ANSI and the interla Excel xml files are expected to be UTF-8. Is the Dbf-File in your previous post exactly the same file from which this faulty xlsx file was generated? Or can you find out the encoding of the dbf? Looking at your Dbf-File in the previous post by means of MyDbfStudio I see that the file is encoded with codepage 1252 (not sure though whether MyDbfStudio extracts the encodings correcttly...). When you now read the strings from dbf you must convert them to utf8 before writing them to fpspreadsheet. The following code fragment (based on your test project) shows you what I mean. It is untested, though, there may still be some typos here and there: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i uses  LConvEncoding; const  DBF_ENCODING = 'cp1252';    // adapt if your "real" file is encoded differently function DBFTableToWorksheet(tableName: string; h: TsWorksheet): boolean;var  ...  tmp, nomCampo: RawByteString;  // they were type "string", but declaring them as RawByteString prevents FPC from doing its own conversions  encoded: Boolean;  // new variable neededbegin  ...    for c:=0 to Dbf2.FieldCount-1 do begin      nomCampo := Dbf2.FieldDefs[c].Name;      h.WriteText(0, c, ConvertEncodingToUTF8(nomCampo, DBF_ENCODING, encoded));         // the call to ConvertEncodingToUTF8 converts the field names to UTF8. Can be skipped if all field names are ASCII (all chars < #128)      h.WriteHorAlignment(0, c, haCenter);    end;    ...      for c:=0 to Dbf2.FieldCount-1 do begin        tmp := Dbf2.Fields[c].AsString;      h.WriteText(f, c, ConvertEncodingToUTF8(tmp, DBF_ENCODING, encoded));   // dto with the field values, but do not skip this!      end;      ...  Give this a try, even if you don't know the correct dbf encoding. Above code makes sure that no invalid UTF8 characters are in the file. And maybe Excel is able to read this file correctly. ---------------------------------------------------------------------- Edson · 2024-08-28 21:23 Hi. That conversion solves the problem. Now the file generated can be opened without errors. I didn't know it was needed to have text in UTF8 to create an Excel *.xlsx. And yes. I used the same DBF I posted in the sample project to generate this corrupted xlsx. I don't know why you don't generate a corrupted file with the same DBF. Thank you very much @wp and @jcmontherock for your support.