I've just upgraded to Excel 2010 (it was free as I bought 2009 recently). I now don't have another version of excel to test it on but I think I've discoved a SUMIF bug. Now I know the chances of me discovering a bug in excel are almost zero, so can someone tell me what I'm doing wrong, or alternatively tell me what their version of Excel does?
Open a blank workbook
In sheet1, put 1 (just the number) in cells C1 to D3 (6 cells - the exact number doesn't matter)
In sheet2, put 2,3, and 4 in cells D1, D2, and D3 respectively
Now in a cell in sheet2 put the following formula =SUMIF(Sheet1!D1:D3, 1, Sheet2!D1:D3)
In another cell in sheet2 put this formula =SUMIF(Sheet1!C1:C3, 1, Sheet2!D1:D3)
As far as I can see, the cells should display the same value, but in my version of excel, the first displays 3 (incorrectly) and the second displays 9 (correctly - the sum of 2,3 and 4.)
The values 1,2,3, and 4 are irrelevant. It seems to be the fact that the letters for the columns match that causes the bug.
Before anyone argues Excel isn't programming I beg to differ.
[ I have since found another bug report on a technet forum: http://social.technet.microsoft.com/Forums/en/excel/thread/cda9fef8-8ad4-4d56-8939-49b1ae50c4e7 - so it might be real ]
Yes, it is a bug in Excel 2007 and 2010 SUMIF and SUMIFS (and related functions).
I've pursued more investigation - it is a bug in Excel 2010 (but not 2007), and Microsoft have now acknowledged it here: SUMIF bug excel 2010. See the posts from Jenny E. No word on a fix yet.
Excel 2003
No. 4 = 9
No. 5 = 0
These two formulas would return the same thing
=SUMIF(Sheet1!D1:D3,1,Sheet2!D1:D3)
=SUMIF(Sheet1!C1:C3,1,Sheet2!D1:D3)
which it seems is what you're driving at.
Related
I am trying to create a google sheet to track some payments and have created some conditional formatting rules to show when there is under/over/correct payments. It seems to work correctly, except for one set. I am linking to a spreadsheet so hopefully you can view it.
https://docs.google.com/spreadsheets/d/1IJ6zFXP2cMRQmbf3KSFEcO_H36CP3sBwp1dfvJMSDmc/edit?usp=sharing
It seems to go wrong on one particular set...line 19 shows that 26 cents is still owed - it shows correct. If you then look at line 14 (it works upwards), the Still Owed shows as $0.00 and not $ - and it shows in red and not white. And from then and upward, even though nothing is owed, it doesn't show right. However, I tried on line 15 making it show a penny is owed, and then line 10, it was paid off and so is $0 owed and it shows right.
I've tried copying the formatting and checking all the columns and I think they all look the same.
Any ideas how to fix it?
You should use Custom formula in Conditional Formatting.
Note: Use VALUE() in Format rules helps you to shorten the content Apply to range, because that ignores text cells
I think it's a (lack of rounding up/down) issue.
I changed the formula in S14 from:
=SUM(F14-G14+K14-L14+P14-Q14)
to:
=round(SUM(F14-G14+K14-L14+P14-Q14),2)
This way it will disregard any decimals beyond the second and thus make $ 0,00 truly 0.
This question already has an answer here:
Google Sheet yields infinitesimal number as remainder of an integer/whole number
(1 answer)
Closed 3 months ago.
I have a Google Sheet with the following values:
12.4840
-8.1870
-0.9630
-3.3210
3.4550
0.3140
3.3470
-7.1290
If I SUM() these, the expected result is 0 (zero). But it is not. The value that Google Sheets returns is actually 0.000000000000000888178419700125. This is super weird, as none of the values have more than 4 decimals.
I found this out after debugging for hours because some conditional formatting is supposed to color every cell that has a 0 value, but this (and some other) cells just would not change color accordingly.
I have an example here: Stackoverflow Google Sheet. Can someone please explain me what is going wrong here, and how I can get the SUM() to return true zero? I have tried everything (format input as numbers, as text, force to numbers in sum() formula) but nothing seems to work.
[Update] I have added a few more examples in the Sheet.
actually, this is not a bug and it is pretty common. its called floating point "error" and in a nutshell, it has to do things with how decimal numbers are stored within a google sheets (even excel or any other app)
more details can be found here: https://en.wikipedia.org/wiki/IEEE_754
to counter it you will need to introduce rounding like:
=ROUND(SUM(A1:A))
this is not an ideal solution for all cases so depending on your requirements you may need to use these instead of ROUND:
ROUNDUP
ROUNDDOWN
TRUNC
TEXT
I have a column with lots of rows containing text. I want to highlight cells with over an x-amount of characters, but how? The code I'm using in combination with 'Conditional Formatting' is not working all the time. Sometimes it highlights text over the x amount and sometimes it doesn't, so there is something I'm doing wrong here. The x-amount in the example below is: 300.
you may also need to lock it like:
=LEN(E$1:E$170)>300
Silly me... I found the answer myself. I need to put in the same range in the formula as well. Formula with the range E1:E170 needs to be: =LEN(E1:E170)>300
Is there a way to automatically highlight inconsistent formulae, just like Excel does?
What I mean is if I have a range of cells with the same formula (structure) but one of those have a different formula, Excel will mark that cell as this is a potential error.
Is this function available in OOo Calc? I've looked at the Detective functions but none of those seem to do the job.
Excel dispenses the inconsistent formula error largely through comparing the R1C1 formula equivalents to adjacent cells since the R1C1 version does not change. If you have numbers in A1:C9 and you total the numbers for each column in A10:C10, the formulas as xlA1 are =SUM(A1:A9), =SUM(B1:B9) and =SUM(C1:C9) but as xlR1C1 they are all =SUM(R[-9]C:R[-1]C) (or =SUM(R1C:R9C) if absolute references are preferred). This makes it very easy for Excel to compare one formula against another to see if they are identical or not as viewed from the R1C1 perspective. So easy, in fact, that the operation can be performed as an on-the-fly background operation.
Unfortunately, OpenOffice Calc does not support R1C1 addressing outside of the INDIRECT and ADDRESS functions. This makes it much more difficult to compare the formulas in adjacent cells as each formula has to be have each internal cell/range address parsed as referenced by the cell where the formula resides. While this is possible through programming, it is not a native OpenOffice Calc capability. There may be some work done in this area (Google should know) but it would almost assuredly be an on-demand macro and not a background operation.
I'm exporting data from a CxDBGrid to an Excel file.
I'm able to create the file and copy data in it, but I'm having real trouble with the column formatting. Since I'm pulling the data from a DB I'd like the spreadsheet to reflect the type: NUMBER, VARCHAR2,DATE and so on.
I visually created a macro, went to look for the VBA code, and replicated it in the Delphi project:
sheet.Columns[K+2].NumberFormat := '0,000'; //Number
sheet.Columns[K+2].NumberFormat := '#'; //Text
sheet.Columns[K+2].NumberFormat := 'm/d/yyyy'; //Date
Number formatting works ok most of the times, but the other two don't.
When I open the generated file, the text columns show up as type "Custom" and every cell displays "-64". If I go to edit a cell, the correct value is actually there.
Date is another issue: the DB's format is dd/mm/yyyy and if I feed it to Excel as-is, it gets all messed up. I tried setting the correct format, but then Excel doesn't recognize it.
Any clues?
I'm also setting column width. That works flawlessly.
The problem is that the assigned values are Unicode strings. Try this:
sheet.Columns[K+2].NumberFormat := AnsiChar('#');
sheet.Columns[K+2].NumberFormat := AnsiString('m/d/yyyy');
You haven't said "how you are doing things manually" which means people have to completely guess what you're doing. So here's my wild guess:
If I assume you're using the Express Spreadsheet component from Developer Express
I have estensive experience with this component. It does not support arbitrary numeric formats. It supports a "money" format (0.00) with exactly two decimal places. It does not support three or one, or any other number of decimal places.
If so, this is a known by-design issue in the Express spreadsheet.
If by manually you mean that "sheet" as you show above is an OLE object and you're communicating via OLE Automation to Excel itself, then you should be formatting CELLS either individually or as a range, and not column objects. I am not sure how column object formats would ever override the cell values, if they do at all. The formatting of cells is generally a cell by cell matter, and must be dealt with as such.
If you really want this to work properly you won't use Excel via OLE automation, you'll get a proper Excel XLS format capable writing library. I was quite sure that you could get proper results directly from the CX (DevEx) db grid, but I would ask on their forums, not here. With a regular DB Grid, I'd just use TJvDBGridExcelExport which comes in the Jedi JVCL, and which works with the regular VCL DB Grid.