An Access DB imports a fixed width text file; one column is mostly dates. When the date is not available, the file's creator actually uses the string "Null" Access puts the row in the table with that field actually null.
But, when the files started coming with different field widths, I copied the DB, tweaked the starting/width values in the input spec, and imported. NOW, all the rows with null get logging in (table)_import_errors as an error converting text to date.
I have found no setting (not that I changed any) to explain it. One difference is that although both DBs are in Access 2000 format, the original is on a machine that still has Access 2000, while the new one is being handled by Access 2003.
Is that a behavior change in the Access version? Is pre-processing the file the only solution?<hr>
Thanks, David. That's what I would have done (except for the Excel part) if it had not fixed itself. I posted that, but apparently someone didn't like the public admission that Access has bugs.
The only thing that changed was that two other columns in the fixed width plain text input was wider. Yet Access "decided" to discard the whole row instead of just the date field for three consecutive attempts. The fourth time, it still reported it as an error but imported the rest of the row.
So, when Access misbehaves for no good reason, try again a time or two, then try explicitly coding the conversion from text.
Two possibilities:<ol> <li>
Use a buffer field or buffer table that imports the date field into a text field. Then you can process that into the appropriate values in the final destination field.</li> <li>
Use a SQL import instead of DoCmd.TransferText. What you do in that case is use a connect string in the FROM clause so you can then process the date field in your SELECT:</li> </ol>
SELECT Sheet1.FirstField, Replace(Sheet2.DateField, "NULL", Null) As DateField FROM Sheet1 IN 'C:\Import\Spreadsheet.xls'[Excel 5.0;HDR=YES;IMEX=1;];</pre>
Convert that into an INSERT query and you're golden.