We are doing Excel JavaScript add-ins development and testing. Excel keeps crashing 1-2 times per day randomly. It may crash with action from JavaScript Pane or without it just using other Excel methods from its ribbon. There is no repeating pattern we have found.
We use Excel Tables, but that's about it. Not even huge tables just some tens or hundreds of lines mostly. One table in a sheet and below 20 sheets. So nothing special. Sometimes pivots and graphs, too. No VBA or COM add-ons installed. 32-bit Excel on 64-bit Windows. On monthly upgrade cycle so latest build and this has been going on since May 2018 so for several months/builds (at least).
This repeats on multiple developers and not a day without a crash. It feels that it is cumulating something, so it does not crash immediately but maybe after 2-3 hours of use. One idea is that could it be related to network change (between home and office)?
So how could we study this if it is our code and Async calls, or if it is something that we could report as a problem for MS to take a look?
We have already changed the way we do async calls to TypeScript style, but no change.
We are approaching the date when this goes to customer hands...so naturally this must be solved first. So will be thankful for any tips and suggestions.
Sami
I had a similar problem with Excel crashing when using a macro. It wasn't the macro because it worked fine on other systems. I tried everything suggested on the forums -- running in safe mode, checking/unchecking 'Ignore other applications that use Dynamic Data Exchange (DDE)', disabling add-ons, etc -- nothing worked. However, eventually I found that uninstalling Office 32-bit on a 64-bit version of Windows and reinstalling 64-bit Office fixed the problem -- finally! Now it works flawlessly. I hope this also works for you!
Related
I have an Excel workbook with a lot going on – macros, external and realtime data sources, etc. – that has been breaking itself roughly once a week for the last month.
The breakage usually manifests itself when running a macro and getting:
Run-time error '-2147319767 (80028029)':
Automation error
Invalid forward reference, or reference to uncompiled type.
The point of failure identified by the debugger never makes sense – the same code has been working for weeks. And the fix I have been using has been to roll back to a saved version of the workbook that didn't throw errors running macros, and it always contains the exact same VBA code that was breaking. So I conclude that something behind the scenes is getting corrupted.
What's going on? Is there a way to avoid this? Is there a way to fix it that's better than rolling back to an earlier saved version of the workbook?
There are plenty of questions regarding this error, and the code changes that fix them never make sense either. The one thing they all have in common is that they make a change to the VBA code that, one deduces, forces Excel to regenerate its pseudo-code.
Further research leads one to frequent mentions of Excel workbook corruption, as well as to a free utility called Excel VBA Code Cleaner. The authors of that utility explain what's going on:
During the process of creating VBA programs a lot of junk code builds
up in your files. If you don't clean your files periodically you will
begin to experience strange problems caused by this extra baggage.
Cleaning a project involves exporting the contents of all its
VBComponents to text files, deleting the components and then importing
the components back from the text files.
Unfortunately they haven't published a version of their utility that works in 64-bit Excel. But one can perform the same thing manually – save all VB code, delete all modules, then recreate them and past the code back in.
UPDATE: VBA Code Decompiler is another freeware utility that appears to accomplish the same thing. There is also a more detailed description of how Office compiles and persists VBA code in its files.
I'm someone who solves problems by looking, not asking. So this is new to me. This has been an issue for years, and it crops up with different computers, networks, versions and completely different code. There is a lot here, so, thank you in advance if you are willing to read the whole thing.
Generally speaking, I write MS Access programs that will open Excel and then create multiple worksheets inside of a workbook using data from Access tables and/or Excel sheets. The process can take a couple of minutes to run and occasionally, it will get an error. I could tell you the error message, but it doesn't matter because it will be different depending where the error occurs. When it occurs I simply click debug and click continue and it... continues. If it errors out again (many loops later), it will happen in the exact same spot.
So, what I start with is to make minor changes to the code. In the current program I'm working on, the error happens when I write to a cell and the value is a value directly from a table. I created a variable, copied the value to the variable and then wrote to the cell. The error moved to a completely different part of the program and it became a "paste" error. Generally what fixes it is to put a wait function at the spot where the error occurs. One second is usually good enough. Sometimes it takes a couple of these, but that usually solves it. It only took one delay per loop this time, so it is working. I just hate causing delays in my program. So... Has anyone seen anything like this before, or is it just me. It feels like a timing issue between Access and Excel since the delays are usually helpful. Thanks in advance.
I dug up my last major Access project that interacted with Word (ca. 2016) where I struggled with similar issues. I see many, many Debug.Print statements (some commented, some still active), but unlike what I recalled earlier in my comments, I don't see any "wait" statements anymore! From what I now recall and after re-inspecting the code, most problems were resolved by
implementing robust error handling and best practices for always closing automation objects (and/or releasing the objects if I wanted the instances to persist)
subscribing to and utilizing appropriate automation object events to detect and handle interaction rather than trying to force everything into serialized work-then-wait code. To do this, I placed all automation code in well-structured classes that declared automation objects WithEvents (in VBA of course) and then defined relevant event handlers for actions I was effecting. I now recall finally being able to avoid weird errors and application hangs, etc.
You also may never get a good answer to a question like this, so despite that I am not an absolute expert on Office development, I have had my own experience with frustrating bugs like this and so I'll share my 2 cents. This may not be satisfying, but after experiencing similar behavior using office automation objects, my general understanding is that interaction between OS processes are not deterministic. Especially since VBA generally has no threading or parallelism concerns, it can be strange to deal with objects that behave in unpredictable ways. The time slices given to each process separately is at the mercy of the OS and it will vary greatly with multiple processors/cores, running processes, memory management, etc. Despite the purpose of the automation objects--to control instances of office apps--the API's are not designed well for inter-application processes.
Although it would be great if old automation code would produces more useful errors, perhaps nested exceptions (like in .Net and other modern environments), something that indicates delays and timeouts within callbacks between automation objects, instead you get hodgepodge of various context errors.
My hardware is old, but still ticking. I often get delays, even if only for a second, when switching between apps, etc. Instead of thinking of it as an error, I just perceive it as a slow machine, just wait and continue. It may be useful to consider these type of random errors as similar delays. If a wait call here or there resolves the issue, however annoying, that may just be the best solution... wait and continue.
Every now and then after debugging these types of issues I would actually discover the underlying problem and be able to fix it. At the least I would be able to avoid actual problems with the data, despite errors being raised, just like you describe. But even when I felt that I understood the problem, the answer was still often to do exactly as you have done and just add a short wait.
I do believe now this is a timing issue. After thinking things through, I realized that I could easily (well 3 hours later) separate the database info from the spreadsheet info and then move the updated code that is causing problems into an Excel Macro. I then called that macro from Access. Not only do the errors go away, but it runs about 4 times faster. It's not surprising, I just hadn't thought of that direction before.
The issue here is ADO connection with Excel - is this still the standard way to read/write excel files within a Dephi XE environment? We're coming up with multiple issues when reading/writing using the ACEOLEDB driver (ACE 12) and this includes
Reading cells with hashtags don't return results
"Invalid Floating Point" when exporting grids.
We've also noticed that there's many versions of the ACE 12 driver out on Microsoft's website (via Access Database driver executables) and they each seem to have different issues with Delphi.
With these things in mind,
Is using ADO with Excel bad at this point?
Does anyone else have these issues and what did you do to resolve them (other than using XLS files instead of XLSX)?
ADO in Delphi is leaning to TDataSet model, which mean strictly tabular data... that excel is not. Each excel sheet has a random cells filled, some of those may constitute quazi-tabular ranges, or may not.
Depending on the installed software you can
1) use Excel application to open XLSX, read the cells and pass them to your program. This is most easy and compatible method, though is noticeably slow due to COM IPC marshalling and switching. There are tricks to fasten it, like hiding Excel window, copying arrays of data instead of cell-by-cell approach and such.
Start exploring TExcelApplication component - http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Component_Wrappers
2) If you do not want to rely on having commercial Excel installed, you may try reading XLSX files with OpenOffice. Vanilla OpenOffice can only read them though, but some other distro's can write them as well. OpenOffice also exposes external APIs both COM-based and HTTP-based. I know there are Delphi projects of Delphi - OOo interacting but personally did not used them and apart of noting that approach i can say no detailed assesment of it.
3) Microsoft also used to sell Office for Developers or such, that gave you Access and Excel kernels as redistributables, that you could pass with your application and install them and use them. Dunno if it is still feasible though.
4) there is a set of commercial components reading and writing those files directly w/o need to have external EXE's doing the job. While that would be the most fast way to work, it would only support some subset of features (which may or may not be ok for your particular goals) and may have troubles with "future compatibility" as Microsoft would roll out updated versions of XLS and XLSX formats (which again may be of some or none concern to you). Like there was TXLSFile for Biff8 format, there is for example OExport library. There is also a component from well known TMS Studio and maybe some more.
5) You can join some open-source project and try to enhance it for your needs, then again that depends upon how much the subset you need.
I know, many people succefulyl use OLE DB to access Excel data, but for me it always sounded as some perversino, because Excel files do not have any internal regular data arrangement at all, less so strictly-tabular RDBMS-like one.
I've really only ever found it possible to manipulate Excel via COM. I've tried alternatives, like ADO, but they always seem so full of archane bugs - or maybe it's just my ignorance.
COM is definitely slow in certain areas. I've used a combination of COM and (within the Excel file) VBA to achieve what I need to do.
Given that Excel is NOT going to go away BUT Microsoft cannot be relied upon not to betray its users by, for instance, doing away with VBA and COM support, it would be great if someone, somewhere (and I wish I had the skills) could create some proper support for Excel from Delphi.
I worked somewhere before where they had an xll that allowed one to track the amount of memory being used in Excel. Also when calls were made to other dlls and xlls these were logged. This was all spewed out to a logfile based on the Excel PID. There was then a solution that could be used to read the log into a format that could be used in a Pivot Table.
I have googled for nearly an hour coming at it from all angles in search terms, but I am just not having any luck. I cannot remember the provider but I am pretty sure it wasn't in house.
Hope people can help.
No responses. Oh well.
In the end I managed to find the answer. It is a utility called Performance Monitor. It is talked about here :
http://www.dailydoseofexcel.com/archives/2007/09/18/performance-monitor/
It is from the book Professional Excel Development :
Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft Excel, VBA, and .NET: The Definitive Guide to ... and VBA (Addison-Wesley Microsoft Technology)
I hope this helps future people searching for this.
I ve heard things like you cannot manipulate tables in C# but can through VBA.
Does any one know what can be done via VBA which cannot be done via C# PIA?
One thing I remember while working on a Excel addin was that the OnAction method of pictures/shapes added on a worksheet will not call into the C# addin which seems like a limitation. You can set the OnAction to a VBA macro only.
This might not be directly related to your question on the differences in C# and VBA but it just crossed my mind when I saw the questions.
Fundamentally, there is no real difference. You can do pretty much anything in either environment, especially if you're talking about VB.net and C# - they are more or less different syntaxes that target the same libraries and platforms.
There are some syntactical differences where certain features of one language do not have direct equivalents in the other, but as long as you have a few basic elements you can write code to achieve the same ends in both.
In some programs you can use VB script (which is a variant of VB) for macros, and in those cases C# can't be used as a direct replacement. But that is a limitation of the host programs, not of VB/C# per se.
edit:
You've changed the question completely now, so this answer is probably no longer relevant.
You cannot debug a problem as it happens on a user's PC with C# because you will not have Visual Studio installed there. With Excel VBA, you can debug from any PC you run the code on.
EDIT (response to Anonymous' comment)
Whilst you can remotely debug this is not the same, as far as I understand. It requires at least the firewall to be opened up to permit the debug traffic (will likely require some major signoff in big corporates) and you cannot debug and repair an ongoing user problem as it happens. Obviously this can't be done with most programming environments, but it was one of VBA's strengths - well, depending on your point of view, I suppose.
i think the most important difference from a business perspective is that with C# you no longer have as many "non programmers" lob managers, etc that can produce code (macros).
The process is inherently more formalised.
In terms of syntax there are lots of differences... but none that are really an issue in terms of the ability to make use of the object model.
Sometimes you will find C# requires a few more lines of code, but in others less. Also you will find that alot of the times where you were required to use System API calls are now redundant.