Click here to Skip to main content
14,665,013 members
Rate this:
Please Sign up or sign in to vote.
See more:
We have had a number of our clients getting a 1004 0x0800A03EC error with 2 of our programs tried to read excel. These are existing programs that have been running for years.

One client did a system restore to get around the problem. (This did not affect our program which has been installed for a while). Another said something about changing the date of her profile. No sure what that meant and she is not technical.

This is happening on Windows 10 and 7 on Excel 2016.

So it is my belief that some Office update has broken something.

We updated here but cannot re-create the problem.

Any ideas anyone!!!!!

What I have tried:

Nothing since I cannot re-create it here.

Asked the client to re-install our program.
Posted
Updated 22-Nov-18 4:22am
v2
Comments
CHill60 16-Nov-18 12:12pm
   
Anything in the Event log? Without being able to see the code we're not really able to help much
QuickBooksDev 16-Nov-18 12:33pm
   
I don't have access to the event logs and not sure what to look for. Clients are just reporting the error and I am not online with them to see it. I will try.
Richard MacCutchan 16-Nov-18 12:29pm
   
Also there are various reports of this elsewhere. Google for 0x0800A03EC and see if any of the suggestions apply to your software.
QuickBooksDev 16-Nov-18 12:35pm
   
I am been googling for several days now. Since these apps have been working at the same clients for years (and here) it is not a coding problem otherwise when the client did a system restore to remove Windows/Office updates but not our app it worked.
ZurdoDev 16-Nov-18 13:27pm
   
You'll have to look in the event log. But we have no idea what the code is trying to do so I'm not sure what you want us to tell you.
QuickBooksDev 16-Nov-18 13:50pm
   
It would be something like this
Resp = ws.Range("A1.C20").value

I am try to schedule time with one of the clients who had the issue to look at the event logs.
QuickBooksDev 19-Nov-18 12:39pm
   
This is what we found in the Application event log

Installation of the Proof of Purchase from the ACPI table failed. Error code:
0xC004F057

This is from 2012 Server system.
QuickBooksDev 21-Nov-18 11:23am
   
Another client did NOT have anything in the event logs. So it looks like the ACPI error was not related.

Rate this:
Please Sign up or sign in to vote.

Solution 2

Not a coding problem? I wouldn't go there so fast.

What was not a coding problem before CAN become a coding problem later because of some tiny change Microsoft made in a patch somewhere to either Excel itself, a data provider you're using, or some security context somewhere. Your code can run into that change expecting some behavior or return value and is no longer getting what it expects back.
   
Comments
QuickBooksDev 22-Nov-18 10:29am
   
You are a bit late with this. This has already been addressed when I answered my own question above.
Dave Kreskowiak 22-Nov-18 12:00pm
   
Yeah, but what I was pointing out was the fact the your code went against convention from the very beginning. Just because it works today doesn't mean it's correctly done.
QuickBooksDev 22-Nov-18 12:25pm
   
I understand that.

But what I don't understand is how can it work in 5 out of 6 systems and most are new office installs on Windows 10. If MS changed their code then it should fail everywhere. If it failed everywhere I would have looked at the code more than a week ago and it would have been fixed. But since it only failed in 1 out of 6 systems it seems more like an update problem.
Dave Kreskowiak 22-Nov-18 14:18pm
   
Probably because they are on a different track for updates. Not everyone gets updates at the same time.
Rate this:
Please Sign up or sign in to vote.

Solution 1

We found the problem but not clear why.

As posted above our code was using a range value of

Ss = "A" & Row & "." & ColNames(UsedColsSht) & Row + 1
s = ws.Range(Ss).value

Note: that a period was used so the range was something like A1.C3 This continues to work in 7 of our 8 systems that we have seen but when we used this format in the excel screen we got a #Field! error. This is a new Excel behavior.

Changing our apps to use a colon instead of a period solved the problem. So the range is now

Ss = "A" & Row & "." & ColNames(UsedColsSht) & Row + 1
or A1:C3

Again it worked in most systems and that cannot be explained. There was nothing in the event logs and the original posting in the header was a false alarm.
   
Comments
Dave Kreskowiak 22-Nov-18 10:24am
   
Why were you using a period to describe the range? That should have been a colon from the very beginning. When you create a range by hand in Excel, it always comes up with a colon to denote a range. It was a bad idea to go against that convention in your code.
QuickBooksDev 22-Nov-18 10:27am
   
The original app was done over 15 years in VB6.

The Excel screens accepted a range with a dot (period) up until a few weeks ago.
CHill60 22-Nov-18 12:22pm
   
I was writing apps 20 yrs ago in VB6 and the range notation was as colon then! As Dave Kreskowiak is trying to point out the code may never have actually been doing what you thought it was, the only difference now is that it throws an exception
QuickBooksDev 22-Nov-18 12:27pm
   
The dot worked also. Worked from the screen and the app.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100