Excel Interop COMException HRESULT 0x800A03EC via C# (.NET 2.0)

Today I'm writing some code to read Excel files via the interop assemblies. I was reusing working code and it suddenly started failing with a COMException which said the error code was HRESULT 0x800A03EC.

I'm using the following code:

string excelLocation = @"C:\test.xls";
Microsoft.Office.Interop.Excel.Application _app = new Microsoft.Office.Interop.Excel.Application();

Workbook wbook = _app.Workbooks.Open(excelLocation,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing);

Worksheet sheet = (Worksheet)wbook.Sheets[1];

/** rest of the code **/

and I get the COMException in the line where I open the workbook.

So, I open the file via regular Excel and I find out it finds the file somewhat corrupt, Excel tells me it had fixed some font and sheet name problems with the file and that if I want to make that fix permanent to save the file. I save the file and then the code works!

But wait, this is not the proper solution if you want a truly automated processing of the files. Given that I don't control the Excel generation process I cannot fix the corruption on the source side of things, so I'll have to fix it on my side.

I started to dig into the Open method parameters and found that the last parameter is suggestively called 'CorruptLoad' so, the solution:

string excelLocation = @"C:\test.xls";
Microsoft.Office.Interop.Excel.Application _app = new Microsoft.Office.Interop.Excel.Application();

Workbook wbook = _app.Workbooks.Open(excelLocation,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, true);

Worksheet sheet = (Worksheet)wbook.Sheets[1];

/** rest of the code **/

And that opens it without throwing an exception and gets all the data in the sheets, at least for this particular type of file corruption.

Wondered this too?

I had always wondered why you only see 3 GB only. Usually simplifying explanations to you need 64 bits OS so see 4GB.

Real explanation is here

There is no hope

If one's to give any credibility to this study, then campaigns like this one stand no chance at all to light up a fruitful dialogue.

Nonetheless I'm glad things like this are happening and the voice of the non believers is making itself heard next to the believers' voice, who usually tend to shout way too loud for anything else to be heard.

Visual Programming Revisited

I find Subtext (soon to be called Juncture) highly interesting, the basic premise is true (we are restrained by text) and the solution looks like going in the right direction, as less work and easier reasoning are always welcome. I still wonder how will that extend to huge systems, but I'm willing to let it pass for now.

Check the video on it and you'll be surprised. You might love it or hate it, but it will surprise you. That's just how it is with great ideas.

You should also check Jonathan Edwards' (the author of this experiment) blog, Alarming Development.

Flames

As much as I hate the pussyfooting, heartwarmingly tender posture of the peace loving, criticism avoiding please don't shout and be quiet crowd:

When we do make mistakes, just point them out politely, there is no need to shout.

and regardless of how much I love the tough, impolite, harsh and rough posture of the flaming crowd:

The common refrain (enumerated in "Why Shout?") is "Can't we all just get along?" The answer is no. No, we cannot. Indeed, every community I've seen in which people "just get along" (usually through strict moderation) degenerates into a feel-good circlejerk devoid of any useful critique. You need only look at a place like DeviantArt to see this in action.

The alternative to this is a community in which criticism is largely unmoderated, inevitably leading to scathing critiques and outright flames.

I think there is a third way.

Disregarding the classical flame concept, which by definition contains personal insults, I propose a new classification:

a) technical flames, where mistakes are pointed out in a rough or hostile manner with no time wasting for politeness (note that in the example the insults are given to the technical contents, not to the person arguing for them) and

b) personal flames, where no technical content is given.

Couldn't a moderation system take care of the latter while allowing the former?

I believe it could. It just needs the proper moderators. Of course there will be controversial content and you have to draw the line somewhere, but just by doing nothing when unsure, that is, by allowing the content stepping on the line, everything should be okay.

I also believe it would be desirable. I'd rephrase the "there's no need to shout" for "there's no need to call somebody an idiot just because he is one". Just let the facts show him as one if you feel that kind of urge. It's harder, but a lot classier.

So true

This is so true. The original source is less interesting, and in my opinion it reads better without the original context.

What are you doing to be above it?

Naming inconsistencies

Look at this, forget everything else you know about these commands or the products behind them and think for a while:

root@parrot:~# my
myisamchk mysqlaccess mysql_client_test_embedded mysqldumpslow mysqlimport mysqlshow mysqltestmanager-pwgen myisam_ftdump mysqladmin mysql_convert_table_format mysql_explain_log mysql_install_db mysql_tableinfo mysql_tzinfo_to_sql myisamlog mysqlbinlog mysqld mysql_find_rows mysqlmanager mysqltest mysql_upgrade myisampack mysqlbug mysqld_multi mysql_fix_extensions mysqlreport mysqltest_embedded mysql_upgrade_shell mysql_print_defaults mysqlcheck mysqld_safe mysql_fix_privilege_tables mysql_secure_installation mysqltestmanager mysql_waitpid mysql mysql_client_test mysqldump mysqlhotcopy mysql_setpermission mysqltestmanagerc mysql_zap

root@parrot:~# pg
pg pg_ctlcluster pg_dump pg_lsclusters pgrep pg_upgradecluster pg_createcluster pg_dropcluster pg_dumpall pg_maintenance pg_restore
(pg and pgrep are not postgresql related)

Same things happen if you start looking at the command line options (try mysqldump --help and pg_dump --help).

So, which one is easier to use? Which one makes more sense? What does this tell you about the two projects? ($)

To me, it says one has organized, well thought, planned development, which transpires the whole product, even to the user interfaces. The other one has haphazard, randomly planned development, which probably percolates from the user interfaces to the code (*), or viceversa.

I'm not saying this demonstrates MySQL as an inferior product. I'm saying this demonstrates MySQL is less organized, cares less about user interfaces and probably is less organized in a lot of other areas as well. I cannot be sure about that, but it sure is the impression it gives to me.

Of course this is not privative to the MySQL project, same naming inconsistencies plague PHP, for instance.

I guess what I'm really trying to say here is that you must take care about all pieces of a project, the more care you take, the better it will look and the easier will be to make it as good as it looks.

What impression is your project giving?

($): Of course one single fact cannot tell the whole story, so please apply standard disclaimers.
(*): I must confess I haven't looked at mysql's code so I cannot know.