Move records to newer db version

[poly_paparas]

Hi

I am not sure I am in the right place but this is my problem.

I have created a database with 10 inter-related tables. I have started using this solution for a couple of months now and it works well.

I have now created a newer-better version of the same solution with slightly different layouts, a few added fields and an extra table, but all the tables and fields of the original db are intact.

How can I import/move all the records into the newer version without losing any information and relations?

Many thanks in advance

Poly

[AudioFreak]

If both files are basically the same just do an import of the old records into the new based on matching field names. If your new file has relationships set up they will continue to work as they do now, just with the added data you imported.

Keep in mind it will import the found set you have in the old file, and after importing into the new file you will have a found set of only the new imported records.

Michael

[Colin Keefe]

If you plan to continue providing new versions of the file on a regular basis, you may want to script the process.

Also, note that you'll need to update the serial numbers on your key fields. That can be part of the scripted process as well.

Thirdly, if you import data from a source file while it's closed, you don't need to worry about found sets in the source file - all data will import.

[poly_paparas]

Thanks for the reply.

What type of export should I do?

Filemaker file

xml file

tab separated text file

comma separated text file

or something else?

[Colin Keefe]

It's not a export so much as an import. In your new file, choose File -> Import Records - File, then select your old file. In the resulting dialog, you'll need to match tables on both sides, and match fields. You'll need to do this for each table.

Hence the scripting suggestion, if you're doing it more than once. It's not hard to do, it's just tedious.

[poly_paparas]

Thanks!!!

I'll get on to it

[poly_paparas]

I tried importing like you said Colin, and it worked well for the main table, but it did not import the related tables, nor could I select the other tables to import them.

I tried going into a layout that draws data from the related tables and that allowed me to import the data for that particular table, but not all of the tables used have an associated layout...

What can I do?

(I have 8 tables in my database and I have only been able to import 3 of those...)

[bcooney]

Are you starting with a clone (that is, no records), in your new version? I would think that that's the easiest way to go.

You need a table occurrence for each table with a layout based on each of those TOs.

Your script will:

1. go to the layout for the table occurrence (destination layout)

2. import from the old version.

You can show this dialog if you want to adjust the import order, or just use the matching field names option. You will need to enter the password for the database each time, or set the source database to have a temporary auto-login so that you don't need to login each time it's accessed. As said above, having the source file closed will automatically pull all recs in the tables and ignore any found sets.

Also, you can set the source file path to a variable or save the path to the source file.

3. sort the records by id descending so that your highest id is the first record.

4. use the script step, set next serial number = _kP_ID + 1

5. go to next destination layout

You'll repeat these five steps for each layout.

This is why you will want to script this. It's tedious.

Edited January 18, 2008 by Guest

[poly_paparas]

Thanks for the detailed instructions, but being a novice not much of it made sense!!!

I'll try reading up a bit about what you suggest when I get some time.

Thanks anyway

[Steverino]

Why can't you just get the maximum value of the Serial Number field?

Is the sort method more reliable?

[bcooney]

Well, you would certainly need a Summary field for Maximum and not just Max(keyfield) + 1, and be sure to show all records. Perhaps it's a speed issue to not use a summary field?