Question

I have an Excel 2007 workbook that contains tables of data that I’m importing into DataTable objects using ADO.NET.

Through some experimentation, I’ve managed to find two different ways to indicate that a cell should be treated as “null” by ADO.NET:

1. The cell is completely blank.
2. The cell contains #N/A.

Unfortunately, both of these are problematic:

1. Most of my columns of data in Excel are generated via formulas, but it’s not possible in Excel to generate a formula that results in a completely blank cell. And only a completely blank cell will be considered null (an empty string will not work).

2. Any formula that evaluates to #N/A (either due to an actual lookup error or because the NA() function was used) will be considered null. This seemed like the ideal solution until I discovered that the Excel workbook must be open for this to work. As soon as you close the workbook, OLEDB suddenly starts seeing all those #N/As as strings. This causes exceptions like the following to be thrown when filling the DataTable:

   Input string was not in a correct format. Couldn’t store <#N/A> in Value Column. Expected type is Int32.

Question: How can I indicate a null value via an Excel formula without having to have the workbook open when I fill the DataTable? Or what can be done to make #N/A values be considered null even when the workbook is closed?

In case it’s important, my connection string is built using the following method:

var builder = new OleDbConnectionStringBuilder
{
    Provider = "Microsoft.ACE.OLEDB.12.0",
    DataSource = _workbookPath
};
builder.Add("Extended Properties", "Excel 12.0 Xml;HDR=Yes;IMEX=0");
return builder.ConnectionString;

(_workbookPath is the full path to the workbook).

I’ve tried both IMEX=0 and IMEX=1 but it makes no difference.

Answer 1

You’re hitting the brickwall that many very frustrated users of Excel are experiencing. Unfortunately Excel as a company tool is widespread and seems quite robust, unfortunately because each cell/column/row has a variant data type it makes it a nightmare to handle with other tools such as MySQL, SQL Server, R, RapidMiner, SPSS and the list goes on. It seems that Excel 2007/2010 is not very well supported and even more so when taking 32/64 bit versions into account, which is scandalous in this day and age.

The main problem is that when ACE/Jet access each field in Excel they use a registry setting ‘TypeGuessRows’ to determine how many rows to use to assess the datatype. The default for “Rows to Scan” is 8 rows. The registry setting ‘TypeGuessRows’ can specify an integer value from one (1) to sixteen (16) rows, or you can specify zero (0) to scan all existing rows. If you can’t change the registry setting (such as in 90% of office environments) it makes life difficult as the rows to guess are limited to the first 8.

For example, without the registry change
If the first occurrence of #N/A is within the first 8 rows then IMEX = 1 will return the error as a string “#N/A”. If IMEX = 0 then an #N/A will return ‘Null’.

If the first occurrence of #N/A is beyond the first 8 rows then both IMEX = 0 & IMEX = 1 both return ‘Null’ (assuming required data type is numeric).

With the registry change (TypeGuessRows = 0) then all should be fine.

Perhaps there are 4 options:

1. Change the registry setting TypeGuessRows = 0

2. List all possible type variations in the first 8 rows as ‘dummy data’ (eg memo fields/nchar(max)/ errors #N/A etc)

3. Correct ALL data type anomalies in Excel

4. Don’t use Excel – Seriously worth considering!

Edit:
Just to put the boot in 🙂 another 2 things that really annoy me are; if the first field on a sheet is blank over the first 8 rows and you can’t edit the registry setting then the whole sheet is returned as blank (Many fun conversations telling managers they’re fools for merging cells!). Also, if in Excel 2007/2010 you have a department return a sheet with >255 columns/fields then you have huge problems if you need non-contiguous import (eg key in col 1 and data in cols 255+)