I code an asp file to response an excel file using Excel.Application object. I change the content type below.
Response.ContentType = "application/vnd.ms-excel"
When user downloads this file and open it, he get the following message.
The file format and extension of 'test.xls' don't match. The file
could be corrupted or unsafe. Unless you trust its source, don't open
it. Do you want to open it anyway?
I don't want to give this message to use. How can I remove this message from excel file.
This is due to a feature in MS Excel called Extension Hardening. There are 2 ways to fix this problem
You need to generate proper XLS files that are truly excel files, not HTML Tables saved with XLS extension
Each of the client machines need a registry tweak as explained here
Related
The file format and extension of 'Accounts.xls' don't match. The file could be corrupted or unsafe. Unless you trust its source, don't open it. Do you want to open it anyway?
It was generating this error while I am trying to open the downloaded excel report from the Oracle ebs
I don't know what to do
the Oracle EBS BI Publisher cannot create real xlsx Excel output files and generates and xml (xslt) format instead, which is given the extension xls to open automatically in Excel. Excel detects that the content does not match the expected binary xls format and shows the warning.
To avoid this problem, you can use third party products like blitz report.
I have created an embedded pdf with the insert> object > create from file> browse > display as icon function in excel.
I would like to then use the embedded pdf as an attachment for my outlook email using vba code. I have tried to use the .Attachment.Add code but it seems to fail to detech an embedded object.
Could anyone advise a correct code? Thanks!
Get the file from the source?
I don't understand why you would need to embed the.PDF object in the workbook, if you're going to be emailing it separately anyhow...
Regardless, you could just grab the actual/original .PDF to attach a copy to the email, directly from the same location from where it was embedded. (If it's not there, what happened to it?)
Another option:
As soon as you right-click the embedded object, Excel 2016 "gets ready" for you to open it by extracting it to your local temp folder. (I'm unsure whether this applies to previous versions.)
Therefore, you could programmatically right-click the embedded icon, and then check the temp folder located at the path that you'll find stored in Environ("temp"). One or more copies of your file will be located there (and it should be the 'newest' PDF).
Yet another option:
Excel's XLSM file is simply a compressed ZIP file, if you change the extension. You could programmatically make a copy of the file, changing it's extension to .ZIP.
Embedded object are stored as .BIN files within the ZIP file in the xl\embeddings\ folder. It would have to be extracted and then renamed back to a PDF. Note that this method is a little flakey and won't work with all PDF's.
More Information:
VBA Express : Save embedded PDF file as a separate PDf file
How-to-Geek : How to Extract Images, Text, and Embedded Files from Office Documents
I have an .xlsx file that when run through the open Office SDK 2.5 generates an error that the document is invalid and contains multiple validation errors involving the slicerCache and invalid attribute values.
I can attach more information about the actual XML if needed from the xlsx file, however my question is actually this. Excel still opens the document without an error. Not even a request to "repair" the document.
I am curious why using the Microsoft open office XML SDK generates validation errors, yet office is still able to open these documents.
Does office make a best guess? Or is the SDK given by microsoft not entirely accurate??
Thanks.
This is a formatting issue as far as I can tell. When you save it in xlsx it saves it as a workbook, not a spreadsheet. I would save it in a different file format or see if there libraries that your sdk needs in order to process the xlsx. I've never worked with office sdk, but I get similar errors when I open xlsx in other programs. 99% of the time I can just change the format. (if you live dangerously you can just manual change the file extension in your folder to something itll read.)
I'm having an issue processing an excel file with SSIS unless I manually open the file and click 'save'.
I've noticed that it doesn't mater if the file is .xls or .xlsx
The file is downloaded to excel from an SSRS project
I am able use a File System Task to move, rename, delete, etc. the file, but when I try to use a dataflow task to access the contents inside the file I get an error that the external table is not in expected format.
I then have to open up the file, click save, and the file processes fine.
Not sure if this means anything but....
I've noticed that when I open the original file in notepad the top line includes with:
xl/workbook.xml
After I save the file the top line changes to:
[Content_Types].xml
Using Microsoft Visual Studio 2012.
ERROR:
Error: 0xC0202009 at TransferMoneyReconcile, Connection manager "Excel Connection Manager": SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft Office Access Database Engine" Hresult: 0x80004005 Description: "External table is not in the expected format.".
ExcelConnectionString:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\192.168.234.567\ftp\Sample\Money\Archive_Transfer Money to Manager.xlsx;Extended Properties="EXCEL 12.0 XML;HDR=NO";
any help/suggestions are appreciated!
Thanks!
Steven
XLSX extension is of 2 types.
Excel workbook (let's call this type 1)
Strict Open XML Spreadsheet (let's call this type 2)
Both the above have the .xlsx extension.
To see this yourself, you can open the excel application, create a new file, click on save and notice the type 1 (located at top of the list) and type 2 (located at the bottom of the list).
The default option is type 1 - Excel workbook. So when you create a new file and save, it will get saved as type 1.
Based on my testing, however, when you open a type 2 file and save, then it may get saved as type 1 or type 2. This behaviour is not guaranteed.
Anyways, to resolve the error you are facing, open the file and save it (via save as) and choose type 1 format. Then test the SSIS, it should run without the error.
This might throw more light on it. The questions remain:
Why can't SSRS output in the standard Excel Workbook format?
Why can't SSIS load the Strict Open XML Spreadsheet format?
I have created a simple Excel file using SpreadSheetGear. If I save it as an xls file
workbook.SaveAs("file.xls", SpreadsheetGear.FileFormat.Excel8);
and attach it to an email, I can open it on my phone (tested both with iPhone and Android).
If I save it as an xlsx file
workbook.SaveAs("file.xlsx", SpreadsheetGear.FileFormat.OpenXMLWorkbook);
and attach it to an email, I CANNOT open it on my phone.
If I open the xlsx file attachment on my computer and save it with no changes and attach it to an email, I now can open it on my phone.
Apparently Excel saves the file differently than SSG. The file size of the xlsx file attachment is 9 KB. When I open it on my computer and save it, the new file size is 24 KB.
Some of my users prefer the xlsx format. Is there anything I can do with to make the SSG generated file attachment open like an Excel generated file attachement?
iOS depends on certain attributes being present in the worksheet data of the Open XML file format to properly parse these files. SpreadsheetGear does not write these attributes out because they are listed as optional in the Open XML file format specification and, also, omitting them reduces file size, as you have noted. Excel, for whatever reason, always writes out these optional attributes and other third-party components often times rely on their presence to function correctly. SpreadsheetGear V5 added a workaround to write out these attributes by enabling a certain "Experimental" option. This option was added because the OLE DB provider also exhibits this errant behavior. You might try something like the following and see if this helps in getting SpreadsheetGear to better work with your viewer:
IWorkbookSet workbookSet = Factory.GetWorkbookSet();
workbookSet.Experimental = "OleDbOpenXmlWorkaround";
IWorkbook workbook = workbookSet.Workbooks.Open(#"C:\temp\BadWorkbook.xlsx");
workbook.SaveAs(#"C:\temp\GoodWorkbook.xlsx", FileFormat.OpenXMLWorkbook);
Please see the SpreadsheetGear.IWorkbookSet.Experimental property for more information on this feature.
From what I can tell, iOS/Andriod/etc often also depend on other certain optional features available in the file formats that SpreadsheetGear either doesn't support or write out by default. For instance, iOS depends on a "data cache" stored within charts to display chart series data points and SpreadsheetGear's support for writing out this data cache is limited. This can result in charts not displaying as expected in iOS, Android, etc.