Hi Ian,
As far as importing of the spreadsheets there is no problem at all.
Make a form in which you have a button and explanation next to it.
Also make a field in which you show progress. Nothing is more irritating then a process running a long time (I just made a similar thing, running for several minutes because of the size of the table) and a time glass showing and nothing happening.
Simple statements like:
X=rst.recordcount
Y=y+1 ‘ per record processed
TxtShowPercent= Y/X ‘textbox fx with 2 decimals and a percent format.
Do not forget a DoEvents statement in the looping, as you will not see a thing running if you don’t have one.
The system will be too occupied for that and the DoEvents gives the user time to even switch windows.
1. use DIR folder\*.xls and a loop with DIR to get through the folder with all(if several?) spreadsheets; putting the path and filename into strPathToYourXls
2. use DoCmd.TransferText acImportDelim, , "tblYourIntermediatTable", strPathToYourXls, True to import the spreadsheet
I, unfortunately, have no experience in how to get a hold on the various worksheets in the workbook, but some experimenting will give you the solution. Do remember that you can do most things in the immediate window
3. the tblYourIntermediatTable is deleted every time you start the process as that will give you a new table with all the column names you need.
4. the rest is a VBA-process of reading the data in your tblYourIntermediatTable and inserting that into the appropriate tables.
I suppose every record will have to do with more then one table as your workbook is not normalized at all.
I am a person that very much prefers to do things in code instead of via query’s. Like making a recordset and reading and writing the whole lot self, as I have the feeling that I have more control over things.
If you start your coding with a On Error Resume Next, you will be able to add many statements like:
DoSomething
If err.number <> 0 then stop
When the code stops, you have all the time to find out the reason why via the immediate window and make the coding more dedicated.
Trial and Error!
:-{) I learned (and taught other people during eleven years) that T&E is a bad way of coding, you should make all kind of schematics first and write ‘perfect’ code after. With nowadays way of coding and visual possibilities I think this is no longer the only truth.
Good Luck
Hans