The problem is in the logic used by the Excel ODBC driver. It treats the spreadsheet as if its rows and columns were rows and columns in a relational database table. As part of this, it assigns a datatype to each column. The problem is, a spreadsheet column may contain mixed datatypes. The ODBC driver makes a best guess at the datatype, based on the first couple of rows of data. Unfortunately, values for any cells that can't be expressed as this datatype instead appear as NULL. Check out MSDN Knowledge Base Q257819 ("How To Use ADO with Excel Data from Visual Basic or VB"), particularly the section entitled "A Caution about Mixed Data Types".

Time and cost estimates -- nothing frightens me more than when my manager walks into my office and begins his sentence with "Um, how hard would it be...".:eek:

I'd suggest creating a message digest from the entered data using secure hashing algorithm such as SHA-1 or MD5. This gives you either a 16-byte (for MD5) or 20-byte (for SHA1) signature that you can then encode in text form using hexadecimal or base64.