Import Script Step

[Genx]

Hi guys,

Just having a bit of an issue with the import. Basically when i do an update, i have to export from 52 tables in order to update the backend. The export works fine, i just export using the layout name of each thing as the name of the exported file (otherwise id forget). Anyway, when it comes to import, i want to import using matching field names, (with the layout name -- which im storing as a varaibel -- as the filename again).. .unfortunatley it doesnt import all the fields like you would expect, it just chooses random fields (probably from older imports)...

Im running FM8v3 ... any advice here, i need to have this automated because it takes to long to manually transfer 53 tables of data (and its dangerous in case i forget a field)

Cheers,

~Genx

[aldipalo]

Hey GenX:

I may be wrong here, but, I thought that once you map the fields in the script step "Import Records" it always returns with "Last Order." Within the import records form you can map the fields you want imported and the key field as well and it will be held when you run the script. I do that between my development database and my working database and it works that way for me with no problems. Of course it is only one table that I

am interested in. As far as doing it for 52 tables or external databases I am not sure how that would be done other than to set each import as an individual script step. But, I must admit that this is not something I do as a regular thing so my experience is limited. It just seems logical.

Al

[Ender]

When an Import order is stored, subsequent Imports are mapped by their relative field order, not by name. In a way this is good because it allows you to rename fields and not have any side effects. The trouble is when fields are deleted, the import order gets thrown off.

I don't really have a solution for you, except to manually perform the Imports (and reset the stored order) when fields are deleted.

I'm afraid the difficulty of having to deal with importing 52 or 53 tables is the trade off you chose when you decided to put all your eggs in one basket. If they were broken into modules, you'd only need to import the tables in the module that was updated.

[K1200]

For what it's worth, I posed this same question (50 table import) to a FileMaker tech support person a couple of weeks ago and was told:

"you have to use Custom Order and do the field mapping by hand"

My suspicion is that the Matching Names import type is a feature that simply got off track somewhere along the line. It's so obvious that a database package should be able to export and import its own table contents when the structure has not changed. Maybe they will address this in 9.0 if enough of us send it as an issue.

[Ender]

I don't think it's a matter of something needing to be fixed. The alternative has a similar problem. If you're always matching by name, then making a minor change to a field name would cause that field to not match.

Edited August 27, 2006 by Guest

[K1200]

My point was simply that when the field names DO match, there should be a provision for an automated import (without the need for manually setting anything up), which would be the default case. Any mismatch at all could kick the user into a manual mode. That would be O.K.

[Fenton]

I agree that it would be nice if Matching Names had a separate option to "use matching names ONLY, redo the order every time". It would difficult though. FileMaker uses the internal IDs of the fields for the order I believe, not the names. It only lets you use the names as a convenience to setup the order the 1st time.

Ender is right, FileMaker is not going to make it the default that Imports would miss data just because someone changed the name of a field. That would cause many users, especially non-developers, to lose data. They would not be happy, to put it mildly.

[Genx]

Meh, i'll just import directly from the old file... that should work right?

[K1200]

Meh, i'll just import directly from the old file... that should work right?

I must be missing something here.

As I tried to explain, my understanding is that there isn't a way to "just import". Exporting the contents of 50 tables is easy -- but importing those contents requires manually setting up 50 corresponding imports (per FileMaker's response, plus my own experience) -- a very time-intensive process.

Are you suggesting there is some other way?

[Genx]

No im just suggesting i import directly from the old file... running it with dialog the first time, and then afterwards, switching it to "last order" and changing any time i add or remove a field (though its not so much an issue, i usually only add tables and fields in tables but anyway..)

[Inky Phil]

I haven't followed this thread thouroughly but I just wanted to point out that I 'just import' all the time. I never export to import.

Phil

[K1200]

O.K., I think I understand. "Just importing" means using the .fp7 file as the source for each table import -- in other words, not having individual exported files for the contents of each table.

My inquiry to FileMaker a couple of weeks ago was actually in regards to restoring the contents of a runtime database if it should become corrupted.

Their response was to "import the contents of individual tables into a cloned copy of the database" -- which implies the existence of exported data sets as a safety net for the user's information.

This is why I was dwelling on the point about having to manually and individually set up imports for each of the 50 tables -- which appears to be the only way. The good news, I guess, is that once they're done, they can be used until a table definition change is made.

[Genx]

Ender... in hindsight, i would split into modules... but this is a commercial product 6 months in the making... plus i find security is hard to manage over multiple files (anyone please feel free to throw me some whitepapers)