gary.humphryes (4/29/2010)
Yes Rich, I spent days trying to crack this and in the end had to cut my losses and battle the SSIS import which in itself proved ridiculously difficult. This is largely do to the inability to set Excel metadata on import which then truncates all text fields to 255 characters. A dark art combination/permutation of IMEX=0/IMEX=1 in the source file connection string and/or padding the source spreadsheet with hidden dummy large text fields eventually got the data in, but as newbie to the asp.net/SSIS environment I hear myself repeatedly asking the same question "why should it ever be this hard?". Not exactly an inspiring start to this environment but at least it's good to know I'm not alone on this one.
Gary, if you want, I can send you the code I used - mostly downloaded from others - to kill the Excel process. I didn't (and don't) like forcing an application closed like that, but in the end, it worked. Here's another good page summarizing the issue and how to address it:
http://devcity.net/Articles/239/4/article.aspx.
I feel your pain about Excel imports. If Excel and SQL Server weren't both MS products, I could understand the mismatches being a problem. MS clearly intended Excel to be a source/destination for SSIS: they didn't do their homework on this, IMO.
That said, once you get it working, it's a good thing to be able to pull in data from Excel. One of the things I use it for is when I need a department to review data for mass updates: I create an Excel file with all the information they need, I add a new column that they use to tell me the row should or should not be updated, then I pull the file back into a staging table with SSIS so I can update the correct data. Saves everyone a lot of time, and I have their Excel file for CYA 🙂
Rich