Another Access Import Problem Cause To Avoid

I just discovered another thing that will cause an import problem when importing data from Excel to Access. I had a formula that was using an if statement to apply a multiplier to a column of numbers – like ‘=if(a1<>””,a1*b1,””)’ I did it to avoid the extra step of sorting the data to handle just the rows where there was data in a1. However, while the formula seem to yield an empty cell it didn’t really and I couldn’t import. When I went back and deleted it from the cells that were supposed to empty (where the else clause of the if statement would have been in effect) I found the import error went away.

Access import trick: Make sure columns are wide enough

So there I am trying to import data into Access, and I’m getting the dreaded subscript out of range error. Grrr….

I went through the usual fixes, but nothing worked. Then I decided to investigate a little. I imported the data into a new table, and then compared the field types of that table with the table I’d been trying to append the data to. Turns out that two date fields were being imported as ‘nvarchar’ instead of ‘datetime’. Hmmmm. I look at the data. All the values in these date fields are ‘######’.

If you import an excel sheet with a column narrow enough that the data shows up as ‘######’ in Excel, the data will be imported as ‘######’. How stupid is that?

Turns out those two date columns were just narrow enough to show the values as ‘######’, and that caused them to be imported as the wrong datatype.

[UPDATE 1-30-2010: Whoops! Turns out that it was a macro I wrote to depivot data that somehow takes the #### literally. Still, it pays to make sure columns are wide enough]

Another trick for bypassing unknown error on Access data import

So I was just trying to import some data into an existing table, and I get unknown error. The existing table had two fields I was importing, one is a varchar, the other an int. The file I’m trying to import was an excel file, but I suspected that Access was interpreting the field that would be the varchar as a float. So I added a line at the top of the file, put a word into the nvarchar field, and a value into the int field and tried the import again – success!

Another Access Trick

So I’m busy importing survey data (an Excel file) into our SQL Server via Access, and I my queries are turning out screwy results. I finally figured out why.

A field that should have been imported as a varchar (i.e. text) is instead being imported as a floating point number. Access was assigning the wrong data type to the field, and then dumping whatever data didn’t fit that data type. That’s because the first few dozen rows have zeros in that field. The text responses don’t turn up until later. Evidently Access looked at the zeros, decided it was a float, and then in the process of importing just skipped any data that wasn’t a float.

When I sorted the file so that text values were at the top, everything comes in fine.

Still an annoying bug, though.