The issue:
Similar to this issue but unable to find a solution I am trying to figure out how to fix this bug:
Viewing an object in Locals or Watch window causes excel to crash
The custom class is as wrapper for ADO execution allowing us to use a separate class to maintain our SQL code and execute it within the wrapper to keep error handling for MS Access ADO execution in one neat place.
This has been great for logging and debugging purposes until a few days ago I noticed trying to expand the node for the custom class in the Locals or Watch windows in the VBA editor cause Excel to silent crash after a 5 second hang and restart with the file recovery window.
Unfortunately the code is company sensitive so I may not be able to paste any in but if there are any ideas as to what might cause it I may be able to find the source and report back.
Has anyone else experienced this issue?
Update: New symptom - During debugging and comparing the text between an older build and the new one I found that the Locals window goes empty (clears of all objects) just after the hang stops and before the crash occurs.
Fixes I have tried:
Rebuilding VBA project and fixing all known compile errors (to eliminate simple vba errors)
Exporting all classes and modules - reimporting into new workbook (to eliminate the workbook file being corrupt)
Copying class and module text into notepad and clearing all formatting - pasting into new workbook (in an attempt to remove corrupt class data)
Disabling any reference to other custom classes to narrow down to a single class.
I appreciate your help and hope my issue can shed some light on it for others.
You can try below things. I hope any one of them work for you. If it still it does not works i request you to
simulate the similar issue for demo and share the code.
Possible issues with add-ins. Try to remove your addins (uninstall
the com addins) and run the code and check if you are still having
the issue.Disabling add-ins is a good test because it let you narrow
the choice of which add-in is causing the crash.
Check whether your antivirus software is up to date or is conflicting
with Excel. If your antivirus software is not up to date, Excel may
not function correctly.
Kindly run the macro on single instance of excel and check if you are
still having the issue. By single instance i mean when you go to task
manager processes tab where only one image name with excel.exe should
appear.
Verify/install the latest window updates
Try to run the same macro on other pc or other version of excel
Use mztools andin and review your code
Related
I'm using a java method to download via agent my multipage dashboard to server file system. When I open the downloaded file I get an error "Excel found unreadable contente in "test.xlsx". Do you want to recover the contents of this workbook? If you trust the source of this workboos, click Yes."
When I click on Yes button, I have a warning "Excel completed file level validation and repair. Some parts of this workbook may have been repaired or discarded."
Data are perfect, nothing is lost, but file is delivered to end users and I can't let it so.
I've tried the same on another environment, where OBIEE 12 is placed, and unfortunately I encounter the same trouble.
I really don't know what to do. We have installed the patch "11.1.1.7.181016" that promises to fix java security trouble in creating the excel file, but with fully unsuccess.
Any suggestion would be great and precious.
Thank you very much.
There's a reason that 11g is outdated and has been replaced with 12c which itself is already on the way out and being replaces by OAS.
The ancient versions have issues that aren't fixed anymore and something that came out in 2013 is expected to not work anymore with other modern software at some point.
It's way beyond time for you to upgrade. And fast. The longer you wait the more problems you incur.
Update: If the bundle patch and the one-off patch 22934699 don't solve the issue then you will be stuck with it.
Alternatively you can switch to CSV for the export since looking at this question here and your other one all you're doing is data dumping.
I created an Excel VSTO add-in, which users can install. However, after using the add-in, the next time Excel is started, the add-in is no longer loaded automatically.
The user can resolve this by enabling the add-in, but it happens every time, and I would like to stop that.
What happens is that in te registry, the key:
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel\Addins\TiaGenerator\LoadBehavior is set to 2, which means inactive by default. I can change it back to 3 (load on startup), but after running Excel, it is changed back to 2.
Edit:
As #Cindy Meister said: Excel should change load behavior to 3 after startup, so there must be a problem. After some searching, it turned out the problem lies within the constructor of a self made class called ErrorWriter. The problem seems to be within this call:
Public Class Errorwriter
Inherits IO.StreamWriter
Sub New()
MyBase.New("C:\tmp\newLog.txt")
End Sub
End Class
Does anyone know why this causes Excel to change the load behavior?
Thanks to the comment of #Cindy Meister, I was able to dig a little bit deeper and here is what I found:
Apperantly, Excel changes the load behaviour of an Add-in if it encounters an unhandled exception during startup.
In the startup routine, I create a new instance of an 'ErrorWriter' object, which inherits from 'StreamWriter', and uses a reference to this file.
What happens is that Excel is loaded, an locks this file. Upon using some functions of this add-in, a second Excel instance is started in the background, which tries to use this file as well. This results in an unhandled exception, but because this second instance is not visible, this error is never shown to the user (nor the programmer).
Because the ErrorWriter is not needed in the second instance of Excel, it never becomes clear that the error occeured in any way.
This causes Excel to change its load behavior.
It is fixed by moving the offending code into a seperate function, which is only called upon invoking add-in functions.
I have thoroughly investigated the problem and found a solution. Changing the "LoadBehavior" is the right way of doing it, but you have to be careful about one thing. Both Outlook or Excel restore the previous settings for each add-in. BUT not at the start of the add-in but AFTER the add-in's start up.
In other words if you attempt to change the LoadBehavior in Windows Registry as part of the startup it will never work. You have to do it afterwards.
I hope this will help.
Thank you, VJ
Hi everyone,
I'am using HP UFT for testing.
I get data from an Excel file and also write data to the same Excel file.
My issue is that when i write data to the Excel file, I can't use it until the test is closed and UFT stops running (UFT won't read it, it's still blank to it).
I need a way to update UFT "view" of the Excel while running, i can't just close and open again the Excel file while test is still running.
Language used: VBScript
Can you help me?
Thank you all
You should use the UFT DataTable. The DataTable utility object gives you ways to import the Excel File programmatically at the beginning of the Test, write the files to there and when it ends, dump it back to a file. As a Bonus, you would also be able to see the DataTable content in the RunReports at the end(under the Data Tab)
Do not forget that everything you do on the DataTable while running the test is written into the memory only. In case the test cannot reach the end where you persist it again, all is lost. You can try error handling with On Error Resume Next, Recovery Scenarios or Class_Terminate based destructors (Create and instantiate a Dummy class, and if the test crashes and stops the Class_terminate will automatically be called where you can do cleanup activities.
I have an Excel Add-in (with a Userform) which connects to an Access database (using DAO) to perform various functions. I've been using this combo for over a decade. Neither the code in Excel nor the database have been changed recently. Just last week, a user reported that one of their functions was taking much longer than usual, so I looked into it. It ended up that the function itself ran just fine, but when the code was cleaning up and ran db.Close it hung up. It doesn't produce an error, it still eventually succeeds, but it takes around a minute to close the db and move on.
I'll go through all of the symptoms and attempted solutions to see if anyone else has any ideas because I'm at a loss.
This only happens when you run db.Execute. I can open the database and close it right away and it closes just fine. If I open it, run a SELECT query to populate a recordset, then close it, it also closes just fine. But if I open it and run a single UPDATE/SELECT INTO/INSERT/ALTER/DROP statement, the Close method will take a minute to run.
My first thought was to compact the db. I cleared out several unused, old tables and compact/repaired, but this did nothing. Same problem.
My next attempt was to recreate the db. I made a brand new TEST db, imported all of the tables from the old one, pointed my Excel Add-in at the new db and did the same tests. Same results.
My next attempt was to try moving it to a local drive (it's on a network share). This slightly reduced the hang at Close, but it's still there. Not that it matters, because this db has to be hosted on a network share.
My next attempt was to delete a bunch of tables from my TEST database. I cleared out about half of them and the hang at Close was reduced a good deal. Clearing out even more reduced it even more. Deleting all but one table eliminated it. So now I know my problem has to do with the size of the db, but why? It maxed out at 500MB after the compact, which isn't that large. It's been running just fine for years. Why all of a sudden would the size/number of tables be such a huge issue? I obviously can't delete all of the tables in the production database just to solve an issue with Closing the connection.
As I mentioned, this code has been around a long time and the prod db was actually in Access 2000 format (mdb), so my next attempt was to change the format. I tried importing it all into both an Access 2003 format (mdb) and the latest Access 2016 format (accdb). The results were the same.
On a lark, I figured I'd trying hitting the db from somewhere other than the Add-in (on the off chance that the problem was in my Excel file). I copied and pasted my test code into a Word 2016 module... and it ran just fine.
That's odd.
So then I tried a brand new Excel file. Also ran just fine.
So I go back to my Add-in and try the code pasted into a Module.
Again, runs fine.
??
So I open the Userform and run my test code again. Hangs up.
??????
I create a brand new Excel file, make an empty Userform, paste my test code in the form's Initialize event.... hangs up.
I immediately run that same code in a Module afterwards... still hangs up. Even though a minute ago it ran just fine in a module in a different file.
But if I close the file, open a new one, paste in the code WITHOUT opening the Userform, and run it, it works fine. Creating/opening a userform will cause all subsequent attempts to run the code to hang.
So here's the Cliff's Notes version:
Excel 2016 DAO connection to large-ish Access database hangs on db.Close under the following circumstances:
1) The db is large (deleting most of the tables helps but obviously isn't a solution).
2) You have opened any Userform at any time during your Excel session. All attempts during OR after the opening of the form, no matter where the code is run from, will hang. Running the code before opening a Userform does not hang.
These results are duplicated on multiple Windows 7 machines, all with what appear to be the latest updates to Office.
EDIT: I was able to try this out on a remote machine running Excel 2013 and there is no hang (using the original Add-in/db that first exhibited the problem). However, that machine is in our data center which is the same place that the network shares are located, so there are at least two possible reasons why it doesn't hang: 1) Different version of Excel and 2) Different/faster network connection.
If you're wondering why I'm using DAO instead of ADO, it's because of what these functions do (lots of stuff with looping through Tabledefs to modify indexes and even create/modify the table Description, which can't be accessed via ADO. If it weren't for all that, I'd just switch to ADO and be done with it. It's possible that I might be able to come up with ADO alternatives/work-arounds for everything that it's currently doing, but I'd rather not rewrite this entire Add-in if I can help it.
I'm at a complete loss on this one, so if anyone has any ideas, I'm all ears.
This is a very common problem when Excel Worksheet or Chart is embedded into Word or Powerpoint. I am seeing this problem in both Word and Powerpoint and the reason it seems is the COM addin attached to Excel. The COM addin is written in C# (.NET). See the attached images for error dialogs.
I debugged the addin and found a very strange behavior. The OnConnection(...), OnDisConnection(...) etc methods in the COM addin works fine until I add an event handler to the code. i.e. handle the Worksheet_SheetChange, SelectionChange or any similar event available in Excel. As soon as I add even a single event handler (though my code has several), Word and Powerpoint start complaining and do not Activate the embedded object.
On some of the posts on the internet, people have been asked to remove the anti-virus addins for office (none in my case) so this makes me believe that the problem is somewhat related to COM addins which are loaded when the host app activates the object.
Does anyone have any idea of whats happening here?
UPDATED 21-JUNE-2010
Found out that both Events and changes to ComAddIns collection creates problems when the embedded object is activated. I have now used the Excel::Application::UserControl property to check whether Excel is in embedded state and then skip any OnConnection(...) and OnDisconnection(...) code.
One solution to Events problem can be to move all the application level events to VBA code and call into .NET. Thereby removing all event handlers from .NET code.
There may be even more scenarios where an embedded object might fail to initialize so I choose to disable the COM addin i.e. skip the code in OnConnection(...) and OnDisconnection(...) methods altogether.
Here is what I did to get rid of this annoying problem:
Remove all event handlers in the .NET code and rely on the VBA Application Events i.e. Instead of handling Excel::Application::Worksheet_Activate(...) event, handle them in a VBA module and call into the addin when an event is received.
The .NET event handlers seems to corrupt the state somehow.
Disable any code that interacts with the addin in OnConnection(...) using the flag in custom param. See the following link for details on the flag:
COM AddIns in Detail
I mentioned about the Excel::Application::UserControl property but it is not reliable in some cases. We need to consider the following cases and the custom array param is OnConnection(...) is the most reliable:
Excel started as independent application
Excel started as embedded app in some other application
Excel started through automation e.g. CreateObject(...)
I preferred disabling the addin totally when Excel is in embedded mode. It depends what code you are executing in your OnConnection(...) and how other applications respond to it when executed. Point #1 has to be implemented to solve this issue.
If anybody has a better solution to this, please let me know :)