Make-table query takes so long

[Dragon]

When I run a make-table query, the results take over 1 minute to
return. The query is making a table that has 12,000 records in it.
If I run the make-table query ONLY to see the records that will be put
into the table, this only takes 5 seconds. It's the making of the
table that takes so long. Does anyone know what I should do to
improve the return time? Also, the new table has a field in it that
is an auto number. However, the auto number field contains data from
the query that is text. Can I create an expression in the query that
allows it to be an auto number. Is this my return-time problem?

[Tim Marshall]

Dragon wrote:

Can I create an expression in the query that
allows it to be an auto number. Is this my return-time problem?

It could be. Are you using macros or code to do this make table query?
If so, why not instead keep the structure of the table intact by first
running a delete query, removing all records. However, indexes and
autonumber fields will remain. Then you can run an append query to add
the new records and you won't need to do anything about the autonumber
field - just don't bring anything to the table, the autonumber ill
populate itslef.
--
Tim - http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Rick Brandt]

"Dragon" <xs*******@yahoo.com> wrote in message
news:3e************************@posting.google.com ...

When I run a make-table query, the results take over 1 minute to
return. The query is making a table that has 12,000 records in it.
If I run the make-table query ONLY to see the records that will be put
into the table, this only takes 5 seconds. It's the making of the
table that takes so long.

This is where you're likely wrong. When you go to Datasheet view of a MakeTable
query Access will display as soon as it has cached in a few pages of rows. This
is not the same as running the query where ALL of the rows are processed.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com