'Too many fields defined' error??

D

D_Pizziferri

I keep getting this error message when I use VBA to export a crosstab query
to Excel, even though the query has only 15-20 columns. The database is
compacted upon each close, and the error occurs even if run just after
opening the database.

Any ideas? This query/transfer process worked fine a few weeks ago, but now
it fails every time, and of course I have a deadline.

Thanks!!
 
T

Tom Wickerath

Try the following:

First, compact the suspect database by opening it, and then manually
compacting (Tools | Database Utilities | Compact and repair database) while
holding down the shift key the entire time, to prevent any startup code from
running. Then close the database.

Create a brand new database and immediately disable the NameAutocorrect
feature (see: http://allenbrowne.com/bug-03.html for reasons why you want to
do this). Then import all objects from the suspect database into the new
database, one group at a time. In other words, import all tables (but not
linked tables), then import all queries, then all forms, etc. When importing
tables, it is a good idea to click on the Options >> button and check the
options to import relationships (unless you suspect corruption in a
relationship), along with Menu/Toolbars and Import/Export Specs. While Access
will allow you to import all objects in one operation, the experts at FMS,
Inc. (a Microsoft Partner), have stated that it is best to import objects one
group at a time (Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

Recreate any linked tables from scratch using File | Get External Data |
Link tables...
Access can cache a lot of information about linked tables, which may no
longer be valid, so it's always best to recreate the linked tables from
scratch. When importing local tables, make sure to check the option to import
relationships, menus and toolbars, and import/export specs. If any of the
local tables in the source DB are hidden, you'll need to first unhide them.
You will need to set the checked references to match the source database,
along with any startup options set under Tools > Startup. Going through this
process often times solves corruption problems, because you get a new set of
the hidden system tables (the tables whose names start with "MSYS"). These
system tables are updated appropriately as you import objects.

This may sound like a lot of work, but it really isn't. Creating a new
container DB, disabling NameAutocorrect, importing all objects one group at a
time, re-establishing any linked tables, setting startup options, and setting
references to match the source DB is usually a fairly quick procedure. When
you are in the Visual Basic Editor, in order to check that the references
match the source DB, you should do a Debug > Compile ProjectName as well.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
±

±ð¼ÌÃ÷

fsdfsdfsdfdf
Tom Wickerath said:
Try the following:

First, compact the suspect database by opening it, and then manually
compacting (Tools | Database Utilities | Compact and repair database)
while
holding down the shift key the entire time, to prevent any startup code
from
running. Then close the database.

Create a brand new database and immediately disable the NameAutocorrect
feature (see: http://allenbrowne.com/bug-03.html for reasons why you want
to
do this). Then import all objects from the suspect database into the new
database, one group at a time. In other words, import all tables (but not
linked tables), then import all queries, then all forms, etc. When
importing
tables, it is a good idea to click on the Options >> button and check the
options to import relationships (unless you suspect corruption in a
relationship), along with Menu/Toolbars and Import/Export Specs. While
Access
will allow you to import all objects in one operation, the experts at FMS,
Inc. (a Microsoft Partner), have stated that it is best to import objects
one
group at a time (Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

Recreate any linked tables from scratch using File | Get External Data |
Link tables...
Access can cache a lot of information about linked tables, which may no
longer be valid, so it's always best to recreate the linked tables from
scratch. When importing local tables, make sure to check the option to
import
relationships, menus and toolbars, and import/export specs. If any of the
local tables in the source DB are hidden, you'll need to first unhide
them.
You will need to set the checked references to match the source database,
along with any startup options set under Tools > Startup. Going through
this
process often times solves corruption problems, because you get a new set
of
the hidden system tables (the tables whose names start with "MSYS"). These
system tables are updated appropriately as you import objects.

This may sound like a lot of work, but it really isn't. Creating a new
container DB, disabling NameAutocorrect, importing all objects one group
at a
time, re-establishing any linked tables, setting startup options, and
setting
references to match the source DB is usually a fairly quick procedure.
When
you are in the Visual Basic Editor, in order to check that the references
match the source DB, you should do a Debug > Compile ProjectName as well.


Tom Wickerath
Microsoft Access MVP
https://mvp.support.microsoft.com/profile/Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top