@Phil_Tremper
The deeper we go, the more complex the story becomes, yet clearer a the same time. Your project involves splitting data into a series of essentially duplicate tables, and the reason is that your data has grown to a fairly large size. On the other hand, 250,000 records may or may not be a problem, depending on other factors,
Splitting data into essentially duplicate tables (e.g. "DataPartOne", "DataPartTwo", etc.) is a less than ideal design for a relational database application. Also, the more important factor is the size of the accdb. If it has grown to over ~1.2 or 1.3 GBs, it's too big to work with effectively. Splitting the data into separate tables in that same accdb does no good in relieving that problem anyway. If you move tables into separate accdbs, you incur additional problems. Plus you lose Referential Integrity on top of that. If the accdb hasn't grown that large (i.e. just over 1GB), it probably isn't crucial yet anyway. Regular compact and repair is usually a good idea one way or the other.
Moreover, I'm tempted to suggest that accidently losing data is just one additional downside to splitting tables this way.
But in any event, it seems like there must be a better way to resolve the problem of size. What difficulties are you experiencing that prompted doing this? If the volume of data and the number of users has grown beyond the comfort zone of MS Access, a more forward looking solution could well be migrating to a more robust database engine like SQL Server Express, which has a 10GB limit versus the 2GB limit for accdbs.
The maximum size for an attachment here is 71MB, so yours should be okay if you want to upload it.
And the references I gave were to internet forums, not apps. Search Google or Bing on those names.
