Intermittent HRESULT error using Invoke VBA (0x800A88C3)

[Paul_Roberts]

Hi, I’ve been scratching my head on this one for a couple of days now and have tried a number of things to mitigate, with no success.

Problem

Running a looping process to generate Excel documents. At the end of the Excel writing process I’m executing VBA code held in a text file to carry out some formatting.

The process produces around 900 documents - the VBA code is erroring on a number of them causing the formatting to not be carried out.

Steps So Far

I added delays - no change
I took the Invoke VBA code out of the single application scope and added it to a separate scope - added a Kill Process between the scopes to ensure the excel is dead - no change
Made the VBA scope visible - no change

I’ve tried to look up the HRESULT error code, but can find no reference to this code at all.

Creating a module in Excel VBA and running the macro from within the application works on the documents that are otherwise failing, so I don’t believe it’s a code issue, although I’m not ruling it out…

Any help would be appreciate.

TIA

Paul

[prasath17 (Guru)]

Hi @Paul_Roberts - Is it possible Use/to run without using Excel application scope? i.e work write range, read range activities .etc…

I have read it somewhere in the forum that, with Try Catch block you can solve this error…

[Paul_Roberts]

Not sure I can use an Invoke VBA activity without an Excel Application scope. Most of the other processing is done outside of a scope, then a small bit of processing is run in the first scope, before I exit and kill the process, then reopen with a new scope.

The process is within a Try/Catch so it doesn’t drop the whole automation. What I can’t understand is why this issue presents on certain files and not others. They’re all basically versions of the same dataset/type (customer statements) so there’s nothing unusual or different that I can see, just the activity fails for some, not others.

[prasath17 (Guru)]

@Paul_Roberts …My bad. Yes, Invoke VBA can only be used in the Excel Application Scope activity.

[Paul_Roberts]

I think I solved it. I still cannot find a reference to that error hex anywhere online, but I did some additional analysis of the logs from Orchestrator. Turns out all of the iterations that threw the error had a similar characteristic:

File Path for the Excel workbook exceeded 190 characters

Added a trim step to my routine to reduce the file path to <190 and the problem is resolved.

Just an FYI in case anyone else hits this issue as it seems there’s a variation between what’s allowed to be written to disc versus what can be handled within the application.