Are you making many changes to the invoice store table in the new database? If not you could export the invoice store as a new FileMaker database and then import it and re-link.
You could also import from V1 to V2, select the invoice store table and let V2 create the new table. Then set up your relations.
1 of 1 people found this helpful
When moving data from v1 to v2 of the same file, exporting is not necessary. You can import the data directly from V1 into V2. I prefer to use a script for this that I have tested ahead of time on a back up copy.
You may also want to research "data separation " to use a method that minimizes the need to import any data at all.
sgljungholm - Thanks.
I'm using InvoiceStore as an example. The application has about 35 tables and this is just one.
The chances are that I am likely to modify all tables in the next version as I move things around to improve the way things are working.
philmodjunk - thanks
I'll look into data separation.
I get the idea of moving from V1 to V2 you talk about but with 35 tables and, on average, 20 fields per table concerns me that one of the 700 fields is going to get overlooked and I was hoping there was an easier way.
It strikes me as strange that as my container fields are stored externally, I can't just export/import the link/external location. Surely that's what the contents of the field actually are?
Data separation does not significantly impact performance in my experience. It does have "cons" as well as "pros" so research and test.
You have less less chance of leaving out a field by importing directly than by exporting then importing. When importing, you can select "matching names" to immediately align all fields that has the same name, you can then fix any fields that are new or renamed. The big thing though, is that you can use one script to do all of this--including the update of serial number settings, then test it on backups to be sure it is all correct before doing the actual update.