I have a script using PHPExcel framework and everything is working perfectly fine except for one big issue when calculating the sum of a column.
It works and the right number is in the cell, the only thing is that when I run the script (and I checked the Excel file I uploaded, no wrong formats there) it converts my TIME cell into a DD.MM.YYY HH:MM cell which corrupts my sum equation.
Whenever I change the field types (formats) manually in Excel, the sum is right and everything works.
What can I do to find and fix the problem?
Related
I'm experiencing an odd error. I have a large dataframe in R (75000 rows, 97 columns) and I need to save it out and then import it into Power Bi.
At first I just did the simple:
library(tidyverse)
write_csv(Visits,"Visits.csv")
and while it seems to export and looks fine in excel, the csv itself is all messed up when I look at the contents in Power Bi. Here's an example of what I mean:
The 'phase.x' column should only have "follow-up" or "treatment" in that column. In excel, looks great:
but that exact same file gets screwed up in Power Bi:
I figured that being a 'comma separated variable' file, there must be some extra comma somewhere, and I saved it as an .xlsx instead.
So, while in excel, I saved that .csv as an .xlsx and it opened great in Power Bi!
Jump forward a moment and instead of write_csv() in R, I use write.xlsx(). But now I get this error:
If I simply go to that file, open it in excel, save it and hit close, that error goes away and it can load into Power Bi just fine. I figure it has something to do with this question on here.
Any ideas on what I might be screwing up as I save it out of R? Somehow I can fix it in R and not have to open and save it every time?
In power BI check that your source has ignore quoted line breaks enabled. I've found this is often an issue with .csv files in PowerBI.
I am using EPPlus to generate an excel report in ASP.Net. I have the following code in use:
aCell.Value = CDec(aValue)
aCell is of type OfficeOpenXml.ExcelRange.
This works fine most of the time. However, when aValue is 201600000000515561, the cell in Excel is set with the value of 201600000000516000.
Stepping through the code and watching the value of aCell.Value shows that the correct value being set. But when the excel is opened, the value has been rounded up to the next 1000.
Does anybody have a solution or is this a bug in EPPlus?
Its not an Epplus thing, more of an Excel thing. Because of the way excel stores numbers you have up to 15 significant figures after which excel basically inserts 0's. If you count 201600000000515561 starting from the left you will see this. Have a look at this:
https://en.wikipedia.org/wiki/Numeric_precision_in_Microsoft_Excel
I think the most popular work around would be to store the numbers as text which of course leads to its own set of issues. Here is a good thread on it:
http://answers.microsoft.com/en-us/office/forum/office_2007-excel/15-digit-number-limitation-non-text-workaround/a4974853-7c3c-4830-8562-2e88369d981b?auth=1
I am reading an XLS file with setReadDataOnly(true). The read object is saved again as a new Excel file. Unfortunately, some cell values are calculated incorrectly (this has to do with a calculation bug over cells with a subtotal formula). If I understand correctly, each cell in an XLS file contains a pre-calculated value along with the formula. If I can get PHPExcel to not attempt to calculate the formulas when reading the file in (instead just use the precalculated values as is) I can get around this issue. I thought that setReadDataOnly(true) or setPreCalculateFormulas(false) might accomplish this, but it does not.
Additional info
Thanks to Mark's explanation, I investigated the difference between getCalculatedValue() and getOldCalculatedValue() in my case. I use the following code to read the file in and then write it out again:
$excel_reader = PHPExcel_IOFactory::createReaderForFile($file);
$excel_reader->setReadDataOnly(true);
$excel_obj_temp = $excel_reader->load($file);
// Test one of the values in question
$excel_obj_temp->setActiveSheetIndexByName("Form 11");
error_log("val:".$excel_obj_temp->getActiveSheet()->getCell("E36")->getCalculatedValue());
error_log("old_val:".$excel_obj_temp->getActiveSheet()->getCell("E36")->getOldCalculatedValue());
$new_file = "new_generated_name";
$excel_writer = new PHPExcel_Writer_Excel5($excel_obj_temp);
$excel_writer->setPreCalculateFormulas(false);
$excel_writer->save($unprotected_file);
When Reading the the file in, it shows the correct value with getOldCalculatedValue(). If I then save the file without setPreCalculateFormulas(false) and read the file in again, both getCalculatedValue() and getOldCalculatedValue() returns the same (incorrect) result. This is inline with Mark's explanation that the values will be recalculated on save if you do not set setPreCalculateFormulas(false)
However, if I instead save the file with setPreCalculateFormulas(false) (which seems to be the correct way) and read the file again, getCalculatedValue() returns the incorrect result and getOldCalculatedValue() returns 0, which is wrong.
Why is the cached values cleared after saving? Is there some other setting I need to apply along with setPreCalculateFormulas(false)?
PHPExcel does not calculate any values when you load a spreadsheet file. It will only calculate cell values if you explicitly call the cell's getCalculatedValue() or getFormattedValue() methods, or by default when you save (unless you use the Writer's setPreCalculateFormulas(false))... though using autofit columns forces a recalculation on save for any cells in those columns regardless of any other settings.
MS Excel will normally save a calculated value for all formula cells in a spreadsheet (unless this is explicitly disabled), and this value can be read in PHPExcel using the cell's getOldCalculatedValue() method.
I am currently trying to import an excel spreadsheet that contains product data for products on my website.
Of the various fields available for product import, one of them is the product description. In this cell, I paste the HTML data that I wish to be displayed on that product.
However, it would seem that sometimes excel decides to format this data on it's own, and after importing, the HTML is all screwed up. It's strange, because this does not happen on every product.
I've tried formatting the cells as "text", but that seems to have no effect. When I paste the values from the cell into notepad, I can see that every singe quote symbol (") has been doubled. For what reason, I have no idea.
The data looks correct when viewed in the cell, but it does not import properly, and the data is visibly changed when copied and pasted out of excel.
Any ideas on how to remedy this? How can I get excel to just ignore the data?
Try putting the HTML code in a single line with no breaks. For example:
<html><body><p><div id="PDG-Team-Image">Test</body></html>
I ran a quick test using the above simple HTML snippet. In Column A, I put the code with line breaks. In column B, I put the code with no breaks. I then copied the cell A1 and pasted it into Notepad, and then copied B1 and pasted it into Notepad. You'll see the first paste (A1) has the double quotes. The second paste (B1) has no double quotes.
I would like to generate an excel sheet aout of a table in asp. The exporting works fine using an in-house developed framework to export the table. The problem that I'm having is that dates are just written in columns as strings and not initialized with the proper cell format. Is there any way to format the date without any 3rd party software by just setting the value of a cell with a string?? Such as:
sheet[i,j].Value = "{:DateTime}"+dateStringProperlyFormatted
I'm not in front of an appropriate box to test this at the moment, but you should be able to format the range with something like:
rangeOfInterest.NumberFormat = "MM/DD/YYYY"
The range could be your single cell, or whatever you'd like. You could also do the entire row with:
rangeOfInterest.EntireColumn.NumberFormat = "MM/DD/YYYY"
There's probably an :"EntreRow" version too, although I don't recall having ever used it.