Import Excel Spreadsheet into Access using SQL...

Good God, don't do it that way.  Use this VBA code line instead...

DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel8, "TestTable", "c:\Temp\Book1.xls", {HasFieldNames: True or False}, {Excel cell range, if anything but the entire sheet}

Hope this helps.
-Jim

Jim is right.
There are commands built into access (TRANSFERSPREADSHEET is the best)
Although you can also link the spreadsheet as a table.

LOL... Good God, I'm working from Excel, not Access.


This is being done entirely programmatically from Excel, not by someone working in an Access database.


The procedure was written (a while ago) to allow the user to upload the file they are currently working on into an Access DB. It currently opens an instance of Access in the background (waste of memory) and uses the TransferSpreadsheet method (the you mentioned above) to import the file,... but I am making improvements to this particular program, and one of those is switching completely to SQL which is more efficient and faster.


I have done this before in the past (quite a while ago), and just need a refresher on the syntax of this particular statement.


WATYF

In that case, it might not be a bad idea to re-post this question in the Microsoft Excel channel.  (After giving danny and me points for moral support...  :)

It might not be a bad idea to export from Excel as a comma-separated text file, then let Access import it as part of its processing.  There could be a lot of probems going from Excel straight to Access, namely table locks, someone changing the Access table definition, etc. etc.

My only comment on SQL would be if your SQL Server is guarded by a Database Administrator (DBA)-type individual, they will likely howl at the idea of letting a super-user export from Excel directly into a SQL Server table.  

Hope this helps.
-Jim

When you did this with text files, I believe you linked to the text file using a schema. Then the resulting Access table can be queried appropriately. If you did the same in the instance of Access and linked to the Excel file, the resulting Access table can also be queried appropriately.  However, you cannot query an Excel file in its native Excel directory. It must first be imported or linked. If it is linked, you cannot update the table, and consequently the Excel file because of formulas and other Excel features which make non-excel updates unwise.

Well... you won't get points for moral support, but you may get them for suggesting the interim step. :o)

This process is a necessary evil unfortunately... I have an Access database that houses tables that are accessed by a UDF in Excel. Most of those tables are built by me (or rather, by a program I wrote which runs on a daily basis). But the users want the ability to upload their own "tables" as they need them. I'm aware of the implications of this, and have gone to great lengths to instruct them on how to "cleanse" their Excel sheets before uploading. It works out OK. Since it's all done through a GUI, they have no way of accidentally corrupting the DB or altering any pre-existing tables.


If I can't get this statement to work, I may have to use an interim step (much like you mentioned above) in which I save a copy of the Excel file as a tab-delimited file and use an SQL statement to import that into the DB. I already have working code that I use to do that (for the tables that my program builds daily). But it requires that I build a schema each time the user uploads a file, and that bring variables into the picture that I'd like to avoid if at all possible...


....which is why I'm attempting to do it straight from Excel in the first place.



WATYF

well... looks like I figured it out.


SELECT * INTO [TestTable] FROM [EXCEL 8.0;HDR=YES;IMEX=2;DATABASE=C:\Temp\Book1.xls].[Data$]


No schema necessary.


Dang... I could swear I tried that earlier too. Oh well.



WATYF

Cool beans man.

WATYF: Good work! I've got A2K and the help files are rather skimpy on this subject. This is a good one to keep tucked away.

Yeah... I'll have the mods PAQ it.

It's a pain, because using SQL directly, instead of relying on the crumbs that Access throws you (i.e. their pre-define methods), just gives you so much more flexibility. There really should be a good place to go to find the breakdown on all the SQL statements that you can use to communicate between Office apps. Standard SQL is easy to find online... but when you get into this weirdness, you don't really have many places to go.


WATYF