Import Records Problem

[Tom Kennedy]

I am trying to create import scripts for my file that has 134 tables to be used to upgrade the file at a later time. I have successfully created the 134 import scripts and have been able to import the data from the old file (FMFile_Upgrade.fp7) to the new file (FMFile.fp7).

However, if I, at a later time, want to copy the present FMFile.fp7 to FMFile_Upgrade and test the upgrade scripts, it appears that the "Import Records" code changes the source table in all of the scripts.

Should this happen?

Is there some other way to do this that I should explore?

[bcooney]

Perhaps my responses on this thread will help. It is not specific to runtimes, at all.

http://fmforums.com/forum/showtopic.php?tid/209924/post/335146/hl/runtime/fromsearch/1/#335146

[Tom Kennedy]

Thanks for your quick response.

My present upgrade system works as you have outlined:

1. I need to know the path to the old file. If you have a consistent install, then you should know the path. However, I use the insert file as reference to capture the old file's path.

2. You'll need a script for each table. The script would go to a layout based on a TO for that table, (delete all records), import from the old file (saved import order), sort and use the SetNextSerial script step to, um, set the next serial ID so that your ID counters will not create records with duplicate IDs.

3. Then I chain the import scripts all together in one big script.

Item 2, above, says that "You'll need a script for each table."

However, your Upgrade demo appears to use two scripts:

1) AutoLocate and Verify Source File

2) Import Table Data

to import all of the three tables (except that the InvLI table did not appear to import properly).

Is the demo a slicker way to accomplish the task?

Does it also eliminate the problem that I experience at present?

Reply update: Ok, I see that you have a script section for each table. However, you don't specify the source in the import code. I have tried to duplicate your import code without success. How do you do this? Is it magic?

Edited November 16, 2009 by Guest
Update to upgrade demo review.

[bcooney]

You don't need an import script for each table, but I find it more manageable than one long import script. It'll also allow you to run one table's import.

I do specify the source in the import records set, it's $SourceFilePath.

Ignore the scripts in MyFile1_00. To create the demo, I duped the files. The final scripts are in MyFile2_00. and you should start at the Main Menu.

[Tom Kennedy]

Thanks again for your input. You have certainly done a lot of work in order to add clarity to the upgrade procedure.

However, when I run the upgrade procedure in MyFile2_00, I can never get the third table (InvLI) to upgrade from MyFile1_00 to MyFile2_00. When I use the Script Debugger, it appears that it is trying to import the Invoices table into the InvLI table and does not succeed. See attached image for details.

[bcooney]

Let me revisit this demo, and see what the problem is. Stay tuned.

[bcooney]

New demo.

UpgradeDemo.zip

[Tom Kennedy]

Thanks again.

I don't see any changes. How did you correct the problem? I thought at first that you refreshed the linkage, but that cannot be the case because you are only specifying the target table.

Edited November 19, 2009 by Guest
Wrong response on my part.

[bcooney]

The INVLI import wasn't correct. It was, as you noticed, using INV as a source. This is a new version.

This may help: when you're building the Import script step, you need to manually select the source file, so that you can see the left side of the import dialog and map your field imports. However, when you are finished, remove the "hard-coded" source file and just leave the $SourceFile as the data source.

[Tom Kennedy]

Thanks for the tip. I have had a lot of trouble working with the import function probably due to needing to know this type of information.

Is it safe to say that with every upgrade, you need to review all of your import script steps due to potential table changes between versions? Would the export/import method eliminate the need to do this review?

[bcooney]

Before every release, I revisit the import scripts. You could just run a test, as if you're a user upgrading, and see how the data looks. But there's nothing really to replace a review of the import mapping.

[Tom Kennedy]

Do you think that the export/import method could eliminate this review - if you used matching names?

[bcooney]

I do use matching names. However, if during development of version3, you've changed the name of a field that you wish to import from version2, then you need to update the import script.

[Tom Kennedy]

I guess if you used the upgrade method, as opposed to the export/import method, you would see the changed field name problem in your review. I don't know if the export/import method would give you that type of information.

Thanks for all of your help.