ColdFusion 8 always opens .XLS, want .XLSX - excel

I am using ColdFusion 8. Doing something like this:
<cfheader name="content-disposition" value="attachment; filename=abc.xlsx">
<cfcontent type="application/msexcel">
<html>
But I get a file like abc.xlsx.XLS.
The reason I'm trying to get an XLSX is because sometimes the XLS version is so large and Office 2007 gets stuck opening it or takes way to long.
Only workaround right now is to wait, open the XLS in Office 2007, save as .XLSX and then open it faster.
Any help is appreciated!

I would suggest that the slow opening is because you are providing the data in an HTML format, not because of the extension. You could test this by saving the file directly from the browser, renaming it with the xlsx file extension, and opening it.
If you want to save data in an Excel format directly, I would check out Ben Nadel's POI CFC project.

I believe that the MIME type for Excel 2007 .xlsx files is "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet". I found an article on the Office Resource Kit Blog that calls this out after googling around a little.

Related

Can I programmatically enable and disable ms-excel file sharing / co-authoring of an xlsx file stored in SharePoint and linked to ms-access?

We have a ms-excel xlsx file stored in SharePoint. This file can be edited in two ways: directly in SharePoint or through ms-access acting as a front-end of the xlsx file (as an external linked table). We want the xlsx file to be edited while the ms-access database is open.
While ms-access is open, the xlsx file appears as read-only. We want programmatically disable the read-only state, so that other people could edit the xlsx file while ms-access is open and, also, enable read-only again when necessary.
I think that the only way to get this is by sharing the xlsx file. My question is as follows:
I don't know whether the best way to share the xlsx file is using co-authoring or using the standard ms-excel sharing. We tried to do it manually using co-authoring, but the xlsx file could not be edited through ms-access.
If we manage to edit the xlsx file through ms-access, then, is it possible to change the shared status programmatically while ms-access is open throug VBA, .NET, VSTO, MS-Javascript API or any other language? I have searched in Google, but I have found nothing but some .NET library for ms-word (Microsoft.Office.Interop.Word.CoAuthoring), but, curiously, not for ms-excel and, as the great wise Confucius said, "if you search something in Google for more than three hours and you don't find it, this means that it doesn't exist".
But maybe someone has had this same odd problem and could help us.
Thanks in advance.
You can't. The first application to open the file will "hold" it, and the next will either could open it as read-only or not at all.
You may be able to let Access open the Excel file, import the data to a table, and then close the file. If the file already is opened in Excel, it may fail, and that you must, of course, take care of.
Another option could be to have a function in Excel that exports the data to another workbook, and then let Access read this.

Convert .xls to .pdf using LibreOffice via Command Line

I'm trying to convert a .xls file to .pdf using LibreOffice via command line on Ubuntu. I have a kind of report on the .xls file with some colors in the background of the cells and etc.
The problem is when I convert the .xls file, the .pdf loses the original format. Each page is broken almost in the half and the content of one page is displayed in two different pages.
Does anybody know how to convert the .xls file to .pdf via command line with keeping the original format?
Or some trick to set the size of the .pdf page to not break pages? (Also via command line)
The code I used to make the conversion was:
soffice --headless --convert-to pdf:"impress_pdf_Export" filename.xls
If you use LibreOffice to convert Microsoft Excel (XLS) files to PDF documents, this is a two-step process (even if your command does look like it is a one-step process):
Import the XLS into LibreOffice (even if started with --headless).
Export the PDF from LibreOffice.
If the result does not look like you expect (not similar enough to Excel's native PDF export), then start with debugging the first step from above:
Open the XLS file with LibreOffice in a GUI. Does it look like you expect it to look? Or are some formatting options looking weird?
Export the PDF from there (with the GUI). Are the page dimensions as you expect? Did you set them up how you prefer? The margins like you want them? etc.pp. ...
If you are working on Windows, you may also want to consider OfficeToPDF.exe. It is hosted on CodePlex, licensed with the Apache 2.0 License and available in binary and in source code.
It requires a working Office 2013, Office 2010 or Office 2007 installation. But then it can commandline- and batch-convert to PDF various MS Office-based file formats, including XLS(X), PPT(X), DOC(X), VSD(X) and PUB as well as Libre/OpenOffice-based ODT, ODS and ODC files.
Although this is a little bit off from the initial question (you don't _really need Office Libre if you have the Office suite and on a Windows machine)
I do appreciate the follow-up provided by Kurt. It prompted me to post the following Gist offering some clear instructions on how to go about using the .exe in a for loop.
https://gist.github.com/einsty/2189cae4175f619cff0f
Try copying appropriate font file (for me it's
a simsun.ttc file) to your libreoffice installing directory like '/opt/libreoffice4.2/share/fonts/truetype'.But if the width of a single excel sheet is too much for a print page(sth like 'A4'),it'll still collapse.

Importing .xls to Access .mdb: External Table is not in the expected format

I have a macro that imports a spreadsheet as follows: (this spreadsheet is an export from a web-based application, and during the initial export the chosen format is 97-2003)
DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel12, "d2s_safety_tbl", _
"\\company.com\dfsroot$\Share\office_public\D2S\D2S\D2S_Scorecard\Source Data\D2S\D2S Safety.xls", True
When importing to Access, I get:
Run-time Error '3274': External table is not in the expected format.
When I open this Excel file, I get a dialog
"The file you are trying to open is in a different format than specified by the file extension..."
So the file name is .xls, my computer tells me its the 97-2003 Format, but once I open the file and click save, it defaults to save it as a Web Page format with the option to save as .xls. What gives?
UPDATE: If I open the file, then Save As .xls format (seemingly redundant, but apparently not), it asks me if I want to overwrite the existing file, so I do. Once I go through this, the VBA import is successful. I can't have the clerk go through this process every week--any way to avoidd this? Possibly the initial export from the web-based application?
DoCmd.TransferSpreadsheet is refusing to import your .xls file because it is not really an .xls file, it is an HTML file that has been given an .xls file extension. Providing a "fake" file extension is a trick that I've seen other "developers" use, and it really is a Bad Idea (for the reasons we've seen here).
If the keepers of the upstream system balk at doing The Right Thing and fixing their code to produce a real .xls file then try renaming the ".xls" file to .htm and importing it using
DoCmd.TransferText acImportHTML, ...
I also got a 3274 error when importing a spreadsheet into Access. I have been using this macro for a while now.
The solution was to compact and repair the Access database.
I had the same problem along with another problem (office 2016 x64): Pasting from excel to access raised 'Data on the Clipboard is damaged,...' error. I found a workaround by clicking on the lower right button in paste section of home tab of access, opening the clipboard pane.
After opening Clipborad Pane as stated above, my DoCmd.TransferSpreadsheet surprisingly worked fine.
I don't know why but it may help those having the same problem and those trying to find a real solution.

an HTML file is NOT an Excel file, right?

we use an application that has an "export to excel" feature that doesn't work on PC's that done have outlook express installed.
i know, you're thinking "WTF does outlook express have to do with excel files?"
i asked the same thing, and here's what i found:
the file being generated is actually one of those Microsoft Single File Web Pages (.mht) and NOT an excel file
you need to have outlook express installed to actually view a .mht file.
i've explained to their support people that just because you can slap a .xls on a file and excel will open it does not mean its an excel file, and does not mean that this is the right way to do it.
how would you explain that this is not proper?
Many people (especially managers) confuse Excel files with reporting files. In my opinion, a file is only qualified as an Excel file if it meets all of these conditions:
Is a spreadsheet formatted in one of the many Microsoft Excel formats.
Can be opened in the most recent version of Microsoft Excel.
Is editable in Microsoft Excel.
In your case, I'm guessing only condition #3 is met, so it's no Excel file. But your support people may still call it a reporting file.
If a clean Windows image with only Excel installed can't open it, then it isn't in Excel format. Period.
If a Windows machine with Outlook Express, but without Excel can open it (if you change the extension) then it can't be an Excel file. I'd combine that with Ignacio's suggestion for a slam-dunk.
Plus, surely if it's MHT, then you can't actually do spreadsheet operations on it? Or am I misunderstanding how it works?
I don't think your statements are correct. Excel (2007) has import and export filters for single-file HTML documents (.mht) even if there is no Outlook Express installed. However, this is not a native format and worksheet features such as formulas cannot be retained (see http://office.microsoft.com/en-us/excel/HP100141051033.aspx#7)
So what you should make clear to your customers is that there is a difference between an applications native file format and a format which isn't designed to contain spreadsheet functionality and that is only supported via an import/export filter.

SWT OleClientSite: How to load XML file in Excel?

I have an Excel file in OfficeML format, MyData.xls. Since I upgraded to Office 2007 from Office 2003 I get a warning message saying that the file content does not match the file extension. It seems that OfficeML now must have the extension 'xml'.
In my application I use OleClientSite to display the file in an OleFrame object. If I change the file extension to 'xml' then Excel is not started. If I leave the extension as 'xsl' then I get the above warning message.
How can I force the file with the 'xml' extension to be opened in the OleFrame using Excel?
The easiest solution is to switch back to the 2003 format, which should not require any changes to your application. To do this, open your file with the extension set to *.xls. When prompted with the warning ("... do you want to open the file now?"), proceed to open (this is a warning to make sure you don't unintentionally open a macro-enabled file). Once in Excel and the file is open, simply save it as *.xls. This can be done by going to "Office Button / Save As / Excel 97-2003 Workbook".
Now, the harder solution will be upgrading your application to deal with the new OfficeML format. I don't know about the component you're using, but it will likely still work for some of the binary parts in the new standard (most notably VBA projects), but you're going to have to unpack and start reading XML files.
If you haven't already done this, create a new Excel workbook, save it as *.xlsx (the 2007 format) and in Explorer, change its extension to *.zip. Open it up and take a look around. For more in-depth on the files, I would start digesting this MSDN article.
Maybe I'm missing something, but shouldn't you just use .xslx as your extension? I'm assuming that by OfficeML, you're refering to Office Open XML.
The <?mso-application progid="Excel.Sheet"?> should be present in the XSL template used.
The below link explains clearly how to include the processing instruction. I had to do something similar and it worked for me.
http://www.shareyourwork.org/roller/ralphsjavablog/entry/generating_excel_sheets_with_xslt

Resources