Error 3349 (Numeric Field Overflow) Only If DB is Split

[David M via AccessMonster.com]

I'm getting the 3349 (Numeric Field Overflow) error when trying to insert new
records into a linked back-end table programmatically. The source is a select
statement from a linked text file (comma sep).

The craziness is two-fold:
1- If I import the destination table to make it local instead of linked, the
procedure works fine. But this is a split db, so the table really needs to be
linked.
2- I only get the error with certain source text files, not all.

So, I can successfully link text file A and select records from it to insert
into the linked table Z. And I can link text file B, but in order to select
records from text file B and insert them into table Z, I have to actually
import table Z (in other words, have a local version of it) rather than have
it linked.

Any clues?

Thanks in advance,
David

 

[Guest]

Probably need to see the code on this one. However if you Dim something as a
Integer and are trying to insert over 33000 rows, it could happen. In that
case try a Long.

BTW: I'm not much of a coder so anyone else feel free to jump in here.

 

[David M via AccessMonster.com]

I came up with a work-around...which is to import the data into a temporary
intermediate table that is local, then transfer them to the linked table.
This seems to work. So the quirk only applies to data coming from SOME linked
text files going into a LINKED table. Other text file sources will work going
into a linked table, and all text files seem to work going into a local table.

 

[JimRussell]

I can confirm (but not solve) your problem with error 3349. To avoid exceeding the Access 2GB limit, I moved some tables which I import into (doCmd.TransferText) to a new backend, and installed links to the moved tables. The import script which had been working, now fails. Because the import specifications do not exist in the backend db, I was unable to test if the import would work there (using local, not linked, tables.) I'm pretty sure it would have.

As ugly as it sounds, I may have to use your approach and import to a local temp table, and then copy the the backend after each of some dozen imports that my script does. Thanks for reporting your problem.

Geeze...