I have a protected worksheet that the provider will not unlock because it has proprietary formulas.
When I use the worksheet in Excel it works just fine. However, when I use EPPlus and call calculate it emits an error 'Number of opened and closed parentheses does not match'. I suspect one of the nested formulas is poorly formatted and Excel is just more tolerant.
Is there a setting to get around this (Like there is for circular references)?
Alternatively a way to scan the whole workbook for which of the nested formulas may be incorrect (so I could get the supplier of the sheet to correct it).
I see there is a module "EPPlus/FormulaParsing/LexicalAnalysis/SyntacticAnalyzer.cs" referenced at https://github.com/antiufo/epplus/blob/master/EPPlus/FormulaParsing/LexicalAnalysis/SyntacticAnalyzer.cs but I can find no examples of how to use this.
Gee, write that there is protection involved and your first thought is I am trying to get around it. I clearly states it just calculated a different result (Excel calculates, EPPlus throws an error). I said that so you would not tell me to change the sheet - I can't. To look at the formula in excel - I can't.
The issue is Excel calculates just fine, EPPlus does not. The evaluation engines differ and EPPlus throws errors when Excel does not.
The Error message said it was the 'Number of opened and closed parentheses does not match', I later figured it out later it was quotes not parentheses. The formula was something like =IF(A1="""", 0, 1).
As it turns out despite the protection, EPPlus does let you circumnavigate the protection and read all the formulas. Thanks for the hint. And it turns out it also cannot evaluate them correctly (to emulate Excel). Its rules are different about quotes. It also has missing formulas (NORMSINV - throws #NAME? error), it fails for circular references that excel does not (when the circular reference is in a VLOOKUP) . Pretty much it cannot be relied on to calculate a sheet as Excel would yet.
Related
I have an excel sheet with a complex formula applied in it. I want to use this formula from my C# code for some calculations. My scenario is like this User fill a form (web) and submit, our program will fetch these values and applied in the hosted excel sheet and get the result.
is this possible?
Help is highly appreciable.
Thanks,
This really should go in the comments section, as I have a few questions to clarify your request. However, as I do not yet have the reputation, my questions must go here.
Is it a formula residing in your existing Excel document that you want to utilize that formula/document without re-writing the code?
Or are you asking if it is possible to write the same formula that you have working on the Excel sheet in c#?
If the former, it is conceivable to pass data into the Excel sheet from the code. After all we can use code to append to other document types, why not an Excel document? And if we can fetch specific lines from other document types, why not from an Excel document (especially since the grid/cell layout provides easier addressable points). However, while it is conceivable, doesn't mean it's easy. It's an interesting proposition, and I'd like to do some experiments on that.
If it is the latter, then depending on the formula's requirements, you may just need to use the appropriate math libraries and write out the formula directly in the c# code. You may not be able to visually see how everything ties together as nicely in the Excel document (with the referenced cells highlighted), but you could modularize components of the formula more easily as sub-functions and re-use values easily enough with variables.
I have an excel spreadsheet that performs complex calculations. I am injecting a value into excel using c#, and then extracting the new value of the calculations in c# also. The problem is the calculation does not happen unless i manually open the excel file and save it.
for example if cell A1 = 1, A2=3 A4=sum(A1+A2)
after updating A1 = 5 via c# the value of A4 is still 4 instead of 8
Is it possible to get the excel file to update without manually opening it? I am currently using EPPplus as interop cannot be run on azure.
Any help would be appreciated even if it's just telling me it's not possible.
Try Spreadsheet Gear. Works great in a server environment as well.
EDIT: The alternative is to use Automation, but I generally advise against it. Too often you end up with memory leaks and crashes.
The excel file has super long formulas and rather than convert them to C# I would prefer to just be able to read from it the result cell after I input values in the calculations cell via the app which would be written in C#
To partially answer your question, If you're not familiar with using the Interop library within C# I suggest you check out this link for basic implementation.
http://csharp.net-informations.com/excel/csharp-excel-tutorial.htm
Then, once you've got your app set up to manipulate excel files check out this one for how to read a value from a cell:
How to read single Excel cell value
HOWEVER, depending on how large your excel file may end up being, it may be a good idea to just go ahead and convert the formulae into C#. Taking a little bit of extra time on that will save you tons of time while waiting for excel to execute statements, as I believe it runs off of/in conjunction with VBA(which is an interpreted language as opposed to C# being a compiled language)
I use the Gembox.Spreadsheet dll to convert a Excel document to PDF by:
ExcelFile.Load(formExcelPath).Save(formPdfPath);
Which works as expected except for one thing: values which are calculated from formulas show up in the PDF as if they were never calculated.
From Gembox's site , it says "Formulas can't be exported to CSV, HTML, PDF or XPS file formats."
However, I do not want to export the formulas, I just want the values present in the cell. Is there a workaround for this? Some way of forcing formulas to be calculated before the conversion to PDF?
EDIT 28-09-2016:
We have released a new version of GemBox.Spreadsheet (version 4.1) in which we implemented a support for cell formula calculation, see the version history page.
Also, you can find the calculation example here.
ORIGINAL ANSWER
Unfortunately the problem is that currently GemBox.Spreadsheet (version 3.9) does not have a calculation engine.
In other words it is able to read the last calculated values from the input file, but it's unable to recalculate formula results on its own.
Note that we do have this feature request in our collection and please feel free to vote for it in order to boost its priority.
But at this moment I cannot tell you exactly when it will be implemented, this feature is not in our current roadmap.
I have a c# tool that creates excel worksheets, which will be later read in again by another tool. This is done by using excel interop.
when reading the generated excel file, an exception stating: OleDbException: Too many fields defined.
it means that the file cannot be read in because there are too amny columns, but there should not be, as the real content only takes about 90 columns. As a workaround i deleted all the other columns manually in excel, and tried again to read it in.
this works as expected, so that means that the generated excel does contain nonempty cells (which are shown as empty cells in excel...)
is there a way to tell the inerop not to create empty cells, or is there another reason i should check?
Many thanks
Tom
PS: I am experiencing this problem with the 2003 interop libraries, while i've got Office 2007 installed.
I've Found the solution:
The tool was copying ranges from one sheet to another.
The source range was properly defined:
GetRange(fromWorkbookName, fromSheetName, A1, V20);
The destination cell hoever was adressed by:
GetRange(toWorkbookName, toSheetName, A1).EntireRow;
In 2003 interop, this seemed no Problem.
When doing this towards an xslx file i Office 2010, some "Empty" fields containing "#N/A" were created.
Nasty nasty...
anyhow the tool was not doing the copy/paste correctly (even excel itself warns you when you copy a range manually to an entire line). After correcting this it seems to work....