I am given a huge excel file with a great deal of data and formulas and I need to access the functionality implemented therein to create a web service running on MacOSX. I tried at first to use POI to access its functionality from Java but unfortunately POI does not support some functions like MINVERSE, TRANSPOSE, MMULT and others and I found it particularly difficult to implement them (also see this question).
Is there a programmatic way to access the excel sheet? I found RCOMClient for R but it seems it works onl on Windows. Perl, Python, R, Octave, C++, Java or anything if fine provided that it provided full functionality over Excel formulas.
Python Excel: Why Python Excel in NOT an option for my problem. In the tutorial it is written that:
A relative reference is useful only if you have external knowledge of
what cells can be used as the origin. Many formulas found in Excel
files include function calls and multiple references and are not
useful, and can be too hard to evaluate. A full calculation engine is
not included in xlrd.
Unfortunately I need a very good support of the Excel engine.
Sure you can.
Have you checked the wonderful Python Excel project ?
Even better : you could take a look at that stupendous blog post.
Have fun and keep us posted if you need more help.
Don't bother accessing Excel from another language than Python, as Python is where you'll waste the lower amount of time.
Related
Excel solver is amazing and wondering if its possible to incorporate the Solver functionality into a web based app instead of keeping everything in Excel. My guess is no because solver solutions are cell based.
On second thought, there is probably a similar solver available with python.
It is possible, but extremely far fetched. You would have to set up Excel on the web server, which makes crazy things to the licensing. Once there, you will have to run Excel in a separate process, but control it from your web app. Using interop in .net might be the least stupid way of doing this.
So just a couple of links to point you in the right direction:
https://www.solver.com/frontline-systems-releases-next-generation-solver-add-in-optimization-excel-online-and-excel-2016
The last few paragraphs point out that you can use the solver with RASOn, JSON C++, R, Python etc in your own apps so that is an option for you.
https://www.solver.com/
Is the homepage of the company that provides the Solver, and access to the more powerful version that exceeds the built-in version in Excel - good though that is. I have not needed the larger version - just turned a model or two around to reduce the computing needs.
Unlike the desktop Excel APIs, which contain a "Precedents" and a "Dependents" on the Range object, the short answer is no for the Excel Javascript APIs, which brings me here.
Is there a way or third-party piece of code to circumvent this huge lack from Microsoft ? If I can't navigate the formula tree, there is just not much useful I can add in terms of add-ins for Excel Online.
Javascript API for Excel
Office Online
UPDATE: to add some context, I've been writing auditing add-ins in C# in the past, to evaluate formula complexity, perform advanced reconciliation of formulas, reconstruct formulas differently, etc... I'm trying to convert a small piece of it, as a javascript prototype add-in, to see whether Excel online can handle it.
I looked at this earlier in the year. The only way at the moment would be to parse out the references from the formula, which is non-trivial (but achievable) given the wide variety of possible reference types.
For a starter look here http://ewbi.blogs.com/develops/2004/12/excel_formula_p.html
And even then you would still have limitations for functions returning references like OFFSET, INDIRECT etc since the JS API does not currently have any Evaluate methods. And to be comprehensive you would also need to handle things like Implicit Intersection etc.
The latest version of the JS API does contain methods for handling Named Formulas, which is a good step forward so a parser would also be able to find references in those.
Why do you want to know a cell's precedents? Is it to implement formula-like functionality so that your add in can enable a function such as =JEROMESUM(A1,A7)?
If so, the JavaScript API has recently added this capability in preview for you to try, called "custom functions": https://aka.ms/customfunctions
Hi I have this code and I want to translate it to any other programming language such as Python Java ruby
As you can see this is a raffle game user presses f5
And generates a raffle number such as Aqua 2231 7533 and stores all entries and at the end makes a random selection
This part is generation part
=LOOKUP(RANDBETWEEN(1,3),{1,2,3},{"Aqua","Blue","Red"})&" "&TEXT(RANDBETWEEN(0,9999),"0000")&" "&TEXT(RANDBETWEEN(0,9999),"0000")
And this part is the random selection
=INDEX(A:A,RANDBETWEEN(1,COUNTA(A:A)))
There are a couple of libraries which may be able to help. I don't know if they support the LOOKUP, RANDBETWEEN or TEXT functions specifically but as they are open source libraries there's potential for you, or someone you know, to add that particular functionailty (all of these projects welcome such input).
The libraries for Python that read Excel and generate Python code are;
PyCel
Formulas and Schedula
xlcaclulator (This is my project)
Koala
In each case these libraries have an "evaluator" which can actually run the generated Python code. Some of these evaluators are integrated with the Excel file reading functionality, in other cases it's separate.
PyCel and Koala2 have the evaluation functionality integrated with the Excel file reading functions. xlcalculator has them in separate objects. Formulas and Schedula have them in separate projects.
It's not easy for them to print out or save "vanilla" Python code due to what needs to happen to evaluate the generated code. The evaluation code needs access to the Python implementation of the Excel formula and, as things are at the moment, all of these projects use their own libraries with their own objects and their own mechanisms to call said objects. xlcalculator has attempted to extract the Python implementations of the Excel formulas to have a library anyone can use but it is also the most recently written so who knows how successful that will become. That library is called xlfunctions.
Providing the above mentioned projects support LOOKUP, RANDBETWEEN and TEXT functions, they will be able to read the function you've written (without the need for Excel to be installed), translate the function into Python code and execute the resulting code in Python.
Shouldn't be that hard.. Just :
Copy the formula & break it up in notepad++
For each function used, read up WORD-BY-WORD its documented documentation.
One you understand the data flow/change/list/start/end in the program.. use your mother tongue language, Ink it (the understanding) down. you may draw if it helps..
In the programming language of your choice, implement the "mother tongue" algorithm in that language.
Test the program with exactly the same input you gave to the original excel formula.. edit if necessary.
Since you didn't share ANY form of tries.. this is the best I have.. which works for me.. sorry if hurts/didn't solve..
Hope someone can improve/edit my answer for the better. (:
Although I've done VBA projects within a single application for both MS Access 2007 and Excel 2007, I haven't automated multiple applications at the same time. The generalized project is to open access, run some update queries that appends data to various tables. Then Excel needs to get the data. Some formating changes are needed in Excel, such as grouping that doesn't automatically change the date range. Finally, I plan to build it out such that the excel file will be emailed automatically.
Some parts of this are clear how to accomplish it, such as Excel will be getting the data by ODBC from Access. But where should the master VBA live? I could have a button in Access that would start running Access VBA, but is it a good practice to have the Access VBA start manipulating Excel? Does that make it difficult to debug?
To get started from Access, add a reference to the Excel object library. Then use the object browser to familiarize yourself with how the Excel object hierarchy looks from within Access. It is going to be somewhat difference, because the top-level object in Excel code is implicit (as it is in Access), and has to be explicitly referenced when coding in Access.
The Access Developers Handbook has excellent chapters on automating the rest of Office from Access.
Last of all, it's best once you've coded using the reference to the other app's automation library to help you program, you want to switch to late binding so you can remove the reference. This means not using any of the external library's specific data types (you mostly use plain object variables) and using none of the constants defined in the external library. My production code with late binding usually includes the early binding version commented out, alongside the late binding version.
I think the keywords you are looking for is "microsoft office automation".
Make an application in you favorite programming language that supports COM interfacing and then use automation to do the manipulations in the different office applications.
Look here c# How to access an excel cell? and here How to read data of an excel file using c# ? and Google.
I have recently done something quite similar to this, and have found that I can output HTML with built-in CSS for formatting that loads quite nicely into Excel. I used Access to allow users to build their required output, only opening Excel to display the results. You may find that HTML output makes for nicer emails.
Do all the work in Access VBA. See the following URLs for some sample code
Modules: Sample Excel Automation
Modules: Transferring Records to Excel with Automation
Also note that if you are dealing with multiple versions of Excel late binding becomes a necessity. Late binding means you can safely remove the reference and only have an error when the app executes lines of code in question. Rather than erroring out while starting up the app and not allowing the users in the app at all. Or when hitting a mid, left or trim function call.
This also is very useful when you don't know version of the external application will reside on the target system. Or if your organization is in the middle of moving from one version to another.
For more information including additional text and some detailed links see the Late Binding in Microsoft Access page.
As far as emailing goes there are a number of options at the Microsoft Access Email FAQ
You may put the code in Access, or Excel. In my experience, that is easier to work with than splitting the code between the two (which also works).
If you find that the automation code runs too slowly, you can split the code, so that Access is run by functions in Access, and Excel from functions in Excel, and the master code just runs routines in both. In this case, you can put the master code where-ever you get the nicest user interface for starting things. I've used C,Access,Word and Excel, and where you put the start button doesn't matter a whole lot if all the code is somewhere else.
If your users or maintainers are more familiar with one application, you may wish to put your main or master code there, but more often I find it is better to put the main or master code with the guts of the application, so that I can have no code at all in the other partner.
From the brief description, it sounds like more work will be done in Excel, so I would put all the code there.
Pulling the data out of Access doesn't even need an Access Application object - a DAO or ADO or ODBC object will work (or even DDE), which will be much faster, much more robust, much easier, much better than having both applications open and automating one from the other.
If you start from Access, it sounds like this project will require an Excel automation object. That works well now, but it is still much slower and more fragile doing it with just Excel and a DAO object.
I haven't done VBA for ages although Access was my entry-point into the world of programming. Moving from Access 97 to Visual Basic was easy and I remember that I wrote a lot of stuff using Access more like a VB-form for doing many kinds of tasks (not necessarily database-stuff).
This is the reason why I think you should stick to Access and from there, with help of VBA, do your stuff in Excel etc..
Good luck
I have an old Excel 4 macro that I use to run monthly invoices. It is about 3000 lines and has many Excel 5 Dialog Box sheets (for dialog boxes). I would like to know what the easiest way would be to change it into VBA and if it is worth it. Also, if once I have converted it to VBA, how to create a standalone application out of it?
I have attempted this before and in the end you do need to rewrite it as Biri has said.
I did quite a bit of this work when our company was upgrading from Windows NT to Windows XP. I often found that it is easier not to look at the old code at all and start again from scratch. You can spend so much time trying to work out what the Excel 4 did especially around the "strange" dialog box notation. In the end if you know what the inputs are and the outputs then it often more time effective and cleaner to rewrite.
Whether to use VBA or not is in some ways another question but VBA is rather powerful and extensible so although I would rather use other tools like .NET in many circumstances it works well and is easy to deploy.
In terms of is it worth it? If you could say that you were never ever going to need to change your Excel 4 macro again then maybe not. But in Business there is always something that changes eg tax rates, especially end of year things. Given how hard it is to find somone to support Excel 4 and even find documentation on it I would say it is risky not to move to VBA but that is something to balance up.
(Disclaimer: I develop the Excel-DNA library)
Instead of moving the macro to VBA, which uses a COM automation object model that differs from the Excel macro language, rather move it to VB.NET (or C#) running with the Excel-DNA library.
Excel-DNA allows you to use the C API, which mirrors the macro language very closely. For every macro command, like your dialogs, there is a C API function that takes the same parameters. For example, the equivalent of DIALOG.BOX would be xlfDialogBox - there is some discussion and example in this thread: http://groups.google.com/group/exceldna/browse_thread/thread/53a8253269fdf0a5.
One big advantage of this move is that you can then gradually change parts of your code to use the COM automation interface - Excel-DNA allows you to mix and match the COM interfaces and C API.
AFAIK there is no possibility to somehow convert it. You have to basically rewrite in in VBA.
If you have converted to VBA, you cannot run as a standalone application. As VBA states Visual Basic for Application, it is living inside an application (Word, Excel, Scala, whatever).
You have to learn a standard language (not a macro-language) to create standalone applications. But you have to learn much more than the language itself. You have to learn different techniques, for example database handling instead of Excel sheet handling, printing instead of Excel printing, and so on. So basically you will lose a lot of function which is evident if you use Excel.
Here is a good artikel about this topic: http://msdn.microsoft.com/en-us/library/aa192490.aspx
You can download VB2008-Express for free at: http://www.microsoft.com/express/default.aspx