> Import or link the Excel data to a "temporary" table. Then manually
> create a new table with the fields you need, including an Autonumber
[quoted text clipped - 19 lines]
>
> Please respond in the newgroup and not by email.
Hi Klatuu,
Maybe I'm missing something, but your description:
>Create an append query that will copy the data from the spreadsheet to the
>table.
[snip]
>Then, rather than importing the spreadsheet, Link to it.
>Run the Append Query.
>Delete the Excel Link (Use the DeleteObject method)
seems backwards to me. How can you create the query if you haven't
created the linked table from which it gets its data?
So I think we're doing basically the same thing:
Create a temporary table (temporary in the sense that it will
be deleted once the data has been appended to the table where
it's needed). This can be either a linked table or a "real" one.
Use an append query to move the data.
Delete the temporary table
As for linking vs importing, linking is neater in principle, but I've
often had problems because the Excel ISAM uses different rules to assign
field types when linking and when importing. So I tend to try one, and
if that doesn't bring in all the data I try the other, and if that
doesn't work either add apostrophes to text fields or export from Excel
to a text file.
Importing does increase the size of the mdb, but compacting seems to
reduce it again. And with the limit of 64k rows in Excel we're not
dealing with big tables anyway.
>John,
>I would appreciate your thoughts on the preference for Linking or Importing.
[quoted text clipped - 34 lines]
>>
>> Please respond in the newgroup and not by email.
--
John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
Klatuu - 18 Aug 2005 21:00 GMT
I see your point, I guess I left out a step. In reality, I would link the
table, create the query, copy it to VBA code as an SQL statement and go from
there. Because of the data import issues, sometimes it is necessary use the
spreadsheet link as a recordset and use code to edit the data and create
records in the target table by hand. Slower, yes, but IMHO the most trouble
free and accurate.
Where I am working now, they were having terrible problems getting Excel in.
I replaced all their manual imports to the method I described above, and we
have had no problems since then.
Thanks for your opinion.
> Hi Klatuu,
>
[quoted text clipped - 72 lines]
>
> Please respond in the newgroup and not by email.