Re: field mapping and import scripts revisited

On Feb 27, 10:23 am, "Ursus" <ursus.k...@xxxxxxxxxx> wrote:
My three cents worth. I'm not sure what you are trying to accomplish, so you
just might need the new import. But generally I would say: why the
re-import? Re-doing what you've already done seems superfluous. Normally I
always tell that when you are repeating what you have already done there
might be another solution.

And if you really need the re-import I would look into a more involved
script. Getting all field names from src, making sure all the fields exist
in dest. Then with the use of a loop and the evaluate scriptstep I would
look to populate the dest table. I haven't worked it out completely, just
working of my head.

Keep well, Ursus

What I often have are sets of records that need to be updated fairly
often. For example, one of my import scripts does a SQL pull, then
uses a key field to match the SQL records with the FMP records to
update several fields in FMP. The solution is for a project that's a
sort of assembly line, and each product being assembled has a record
and that record is updated as the individual products complete
successive stages of the assembly process. Up to me, I'd do a manual
import every time, but naturally I want the update process to be push-
button simple for the client. So when the field mapping gets screwed
up it messes with that.

I like the sound of your suggestion, Ursus, thanks. It may be a
little beyond what I know how to script in FMP right now but I'm
definitely going to explore it. If there's a way to solve this field
mapping issue it would really be useful for me with the solutions I
specialize in.

--
FW

FileMaker Pro 8.5 on Window XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server


"FastWolf" <wolfsof...@xxxxxxxxx> schreef in berichtnews:18c90ce5-92df-426c-941d-619e1f107a88@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

field mapping revisited

First, sorry this post is so long and convoluted, Second, please know
that I've gone through everything in this ng's archives regarding the
topic without finding an answer to this issue.

Okay, conventional wisdom is when you script a data import, FMP saves
the field mapping. Even if you do a manual import using the same
source file and destination table, but with different field mapping,
FMP retains the mapping that was scripted. And this is correct, as
far as it goes; but it doesn't go far enough.

1) I created two FMP databases: src.fp7 (we'll call it src) and
dest.fp7 (dest). The files are identical in structure: 1 table, 6
fields, all text, with 1 being a key field, thus:

src dest

f01 f01
f02 f02
f03 f03
f04 f04
f05 f05
fkey fkey

To begin, dest.fp7 has no records in it; src.fp7 has 4 records in it,
with each field being the numbers 1 thru 5 spelled out in different
languages (one thru five; eins thru funf; uno thru cinque; odna thru
pyat. I did that so I could have unique yet matching data to compare
the records, if that makes any sense. <g> ). For the keys I used the
letters a thru d. So the first record in src looks like this:

f01 = one
f02 = two
f03 = three
f04 = four
f05 = five
fkey = a

... with the other three records arranged the same way, i.e with the
word data matching the field's number, and the key incremented by one
letter.

2) In dest, I manually import all the records from src, simple add
records, fields mapped to matching names:

src dest

f01 --> f01
f02 --> f02
f03 --> f03
f04 --> f04
f05 --> f05
fkey--> fkey

3) In dest, I script an import from src, no dialog, update matching
records (on fkey), fields mapped to reverse the sequence on each
record:

src dest

f01 --> f05
f02 --> f04
f03 --> f03
f04 --> f02
f05 --> f01
fkey = fkey

... and so forth. Import Records is the script's only step, it has no
other steps in it. I run the script; no problems.

4) I do several manual imports, update matching records, using several
different field mappings, none of which were identical to the script.
All of them work with no problems. Then I run the import script. No
problems: the script did save the original, correct field mapping.

Still with me? I'm grateful. Here's where the *fun* starts:

5) Now I add a few fields to both src and dest. This time not all the
new fieldnames are identical in both files; and I number them so they
get placed between existing fields when sorted by name. Now the two
files look like this:

src dest

f01 f01
f01.5 f02
f02 f03
f02.5 f03.5
f03 f03.7
f03.5 f04
f04 f04.4
f05 f05
fkey fkey

6) Here's where the fun begins. When I run the import script after
these changes, FMP does retain the original field mapping from prior
to new fields being added to the files. But, it ALSO maps the new
fields to each other, willy-nilly, all by itself:

src dest

f01 --> f05
f02 --> f04
f03 --> f03
f04 --> f02
f05 --> f01
fkey = fkey
f01.5 -> f03.5
f02.5 -> f04.4
f03.5 -> f03.7

Note that the 2 fields with matching names weren't even mapped to each
other. The point is, I never changed the field mapping in the script;
I didn't do a manual import after adding fields and before trying the
script; I didn't do ANYTHING except add 3 new fields to each file,
then immediately run the import script.

Maybe it's just me, but this is really becoming a real headache. I
can't remap all my import scripts every time I add a field to a
table. Has anyone else encountered this (surely someone has)? Am I
missing something obvious or doing something wrong? I sure hope so.

thanks to all

--
FW

FileMaker Pro 8.5 on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server

.