I'm trying to mess around with some dashboard/BI tools since Power BI is no longer free and stumbled upon Power Query/Power Pivot as a potential solution.
I installed Power Query (x32) and am since unable to load excel 2010 when the add-in is enabled. When I disable the add-in Excel opens with no issues. When I re-enable the add-in Excel hangs for a brief moment and then crashes.
I'm running on a 64-bit Windows 7 machine with a 32 bit Excel 2010 installation.
Any thoughts as to what could be going on here?
Edit: Many of my coworkers are having a similar issue so it may be something corporate-wide.
I previously had that scenario at one client, and it turned out to be a clash with a specific Add-In - ironically Microsoft's Data Mining Add-In (for SQL 2008 R2).
I suggest first turning on the Developer Main Tab in your Excel ribbon (for convenience) and then using it's Excel Add-ins and COM Add-ins buttons to disable all other Add-ins besides Power Query.
BTW performance of Power Query on Excel 2010 is truly woeful compared to Excel 2016 (where PQ is also built in, not an add-in).
BTW2 Power BI Desktop and a personal powerbi.com account are both still free.
Related
Excel addin which uses Excel API 1.2. Add-in loads fine in Excel 2016 for Windows and Excel online. Save the file from Excel online and open in Excel 2013, addin fails to load in Excel 2013 with following errors:
When loading the Addin published in Store:
APP ERROR We can't load this app because we could not connect to catalog
When sideloading the addin from trusted catalog:
This app could not be started. Close this dialog to ignore the problem or click restart to try again
I know that Excel 2013 does not support Excel API 1.2. Could you please confirm the recommended way to make sure the add-in loads in Excel 2013?
• Should we use runtime checks using isSetSupported method?
• In such cases, how to debug which line of code is failing in Excel 2013 client?
• Is there any logging that can be enabled to troubleshoot such issues in Excel client?
I tried debugging a default add-in created by VS 2015 which uses Excel 1.2 API in Excel 2013. I added the following requirements set to the Manifest:
<Requirements>
<Sets DefaultMinVersion="1.2">
<Set Name="ExcelApi" />
</Sets>
</Requirements>
The addin also fails to load in Excel (15.0.4849.1003) when debugging using VS 2015. It works fine in Excel 2016 client.
I think there are two separate issues here (though there's a good chance that they're related, and the platform is simply giving the wrong error string. If so, let's confirm, and then I can file a bug to have us fix this).
Excel 2013 does not support the "ExcelApi" requirement set, which is a 2016 addition of the host-specific APIs (same goes for "WordApi"). If you specify ExcelApi in the requirements section of the manifest, as you have above, this will always fail to load in Excel 2013 -- by design. Essentially, you're requesting an API set and marking it as "required" for something that Excel 2013 does not support -- so it has no choice but to refuse to run it.
This is where the runtime check (isSetSupported) comes in. Please see my answer at Neat ways to get environment (i.e. Office version) for more details.
I am not sure what you mean by "how to debug which line of code is failing" or troubleshooting techinques. Essentially, any call to an Office 2016 API (anything in the ExcelApi set) from 2013 will result in a runtime failure...
Hope this helps!
I made a excel spreadsheet using office 2013 and it works fine. But when i try to open it in office 2010 it will crash when retrieving data.
My configuration: office 2013 - x64
Client: office 2010 - x32
data source: odbc
I have no clue what is wrong,
what have i tried:
if i do click on edit query and run the query it runs but as soon as i hit the button to take the data back to office it will just crash.
Have you tried installing powerpivot for office 2010?
This may give you a cleaner and more powerful solution, adaptable in both versions of Excel
I am supporting a legacy application that was written in Access 2003 using VBA. We are updating our systems to Office 2010, with the exception of Access, which will remain the 2003 version. (This is due to several factors pertaining to other groups in my organization.)
We use Access as a front end for running reports out of MS SQL and Sybase databases. Some of these reports open in Excel. During testing, running reports that write to an Excel workbook causes the Access application to crash and exit without a warning message - the application simply disappears from the screen.
I'm not sure what the cause of this is or where I should start looking for answers. Has anybody dealt with a similar situation?
I saved and recompiled the application on the development machine that had Office 2010 installed, and thereafter the application worked correctly with Office 2010 (of course, it no longer works on machines only having Office 2003.) This was, of course, after checking the references were correct. Without any intervention, the reference to Office was for 2010.
After testing with early versus late binding, it would appear the best answer to this issue is to use late binding.
Make sure you are writing to Excel in Excel compatibility mode (.xls).
I wrote a Word 2003 add-in that uses the 2003 PIAs for early-binding. I want the same executable to support the Ribbon interface in Office 2007 and 2010, while still running in Office 2003.
Is it possible to late-bind the IRibbonExtensibility interface? If not, is there another way to dynamically differentiate between Office versions?
There's a good book on working with the ribbon UI in Office:
RibbonX: Customizing the Office 2007 Ribbon
Robert Martin, Ken Puls, Teresa Hennig
The authors and MS both suggest a trick along these lines for solving this problem:
When your add-in loads, it queries the app to find out what version it's running in.
If Office 2003, it creates a normal CommandBars 'n Buttons UI.
If Office 2007 or later, it looks for another add-in and demand-loads it. This second add-in contains just the RibbonX code to create your ribbon UI plus handlers for the button click events. The handler simply calls back to the main add-in.
With a little clever use of tags in your RibbonXML and handler, you can have a single handler work out which routine in the main add-in to call.
I've been working intermittently on an Excel spreadsheet for a customer that does some pretty intense calculations. We implemented a security procedure using VBA... At first the requirements were relatively simple, and the overall lack of security in a spreadsheet was discussed and well understood.
Since then the customer has decided that he would like to have the sheet a bit more secure. Under normal circumstances I would simply disable the developer menu via code. Unfortunately I just recently found out that the customer, and many of his customers, are using Mac Office. (There are some customers that are even using 2008 and they found out the hard way that 2008 stopped supporting VBA)
My question is; is it possible to disable access to the Visual Basic editor in Mac Office in versions Pre 2008, and versions 2011 and after since from the research I've done so far points to a return of VBA support in Mac Office in 2011.
Unfortunately I do not have access to a Mac Office version to even really look through the application and or/test different solutions. In Windows it is possible to right click the VBA project and choose protection from the VBAProject Properties and choose "Lock project for viewing". Does this option exist and is it effective in Mac Office?
Any help/suggestions would be greatly appreciated.
I'm pretty sure you can lock projects in Mac Office the same way you can in Windows. Keep in mind that a project that has been locked in one version of Excel cannot be unlocked with a different version. So, if your customer needs to be able to unlock, they will need to use the same version of Excel you used to lock it.