BUG : Beware of deleting fields that will mess your imports

[genevieve charbon]

Hi,

If you import one filemaker file to another, filemaker ddr export stupidly display the imported field as it's FMP creation order. So it looses the name of the field which is imported and shows something like this

Import Records [ Source: “file:Bible Articles.fp7”; Target: “products_to_ranges”; Method: Update matching; Add remaining; Character Set: “Windows ANSI”; Field Mapping: Source field 1 match with products_to_ranges::Ref absolue product

Source field 4 import to products_to_ranges::import garbage

Source field 734 match with products_to_ranges::id_gamme

Source field 742 import to products_to_ranges::Gamme prioritaire ]

of course the destination field is kept.

Unfortunately, when you delete fields, the order changes, so all your matches goes wrong. That's so dumb,FM should keep the FieldID and not the Field order as the key.

So after deleting fields, you have to rematch all your imports.

Filemaker should fixes this bug urgently so we won't have issue anymore whenever we delete a field

P.S }:| Of course that's not a BUG per say. Filemaker Inc. Took the easy route and considered all imports to be equal, and then decided to apply the method it uses with text files (for which tey only have tab order of fields) when Filemaker file are the source.

[Ender]

I agree that this is an annoyance, but it's not a bug. This has been this way for a long time, and if you consider the alternative, it looks like it's by design.

Imagine if your import map was done by Name instead. Then what happens if you change the name of a field? Same problem.

[genevieve charbon]

That's why I talked about FieldID.

Everything in FMP is based on FieldID (because you can change name), why not for imports.

I know that's not a bug per se, but it is because I think many newbie can get caught with that because it appears you can delete fields, rename them with no harm. Then it shouldn't ever do any damage to the solution.

Futhermore, I'd love that rather than downplaying, defending FMP Inc. with statements like it always have been, the Filemaker community should say "Come'on FMP Inc, how do you dare to let this like that, It's has been a annoyane ffor 15 years ! Move your but quick"

If The FMP comunity would have been more vocal, maybe we wouldn't had all the issue we suffer and that renders Filemaker a nightmare when your solution gets big (non sortable scripts in script maker for instance)

Edited October 26, 2006 by Guest

[John Mark Osborne]

I think the point that Ender was making is that if FMI modified the import mapping to meet your needs, others would complain that it didn't do what they wanted. I don't know if there is a perfect solution but FMI puts a lot of thought behind how to implement a feature and it shows in their final product. I know because I've sat in on planning meetings when I worked at Claris.

If you want to make a suggestion, please visit the following URL:

http://filemaker.com/company/feature_request.html

And, yes, FMI reads suggestions. I know because i was the guy who used to read all the suggestions. About 75% of them turn out to be technical support. The other 25% get forwarded to marketing who shares them with the development team. Complaining about the issue on a forum is not going to get you anywhere. Make a suggestion so the people who create the product can hear about it.

[Lee Smith]

Hi,

Unfortunately, when you delete fields...

Why are you deleting the fields?

I was taught years ago to never delete a field, because doing so, has a tendency to present other problems like this.

Lee

[genevieve charbon]

Thanks for the link John,

I've send them my request (striping out the rage }:|-))

While I, of course, believe that filemaker reads the requests, something must go wrong in the decision chain, because 15 years without sorting in scriptmaker window or horizontal portals is hard to swallow

Sure that kind of feature doesn't show up nicely on a what's new pages, so that's not marketing…

[genevieve charbon]

Why I deleted fields ?

Because I can !

nothing prevents it.

Worse (better actually), whenever deleting a referenced field in a calc or realtionship, Filemaker as it should, nicely warns me I shouldn't do it.

That means to the user, deleting and having no warning is safe, because usually Filemaker is nice.

That's why I call this a bug, because Filemaker let me think he's nice while it stabs me in the back !

If you'd design an FMP solution, withut disabling the delete menu item, and that your client would delete something he's not supposed to. Everybody will call you (the developper) moron.

As Filemaker inc. is the developer of that particular solution which is Filemaker, If it lets me doing harm without warning, then I call FileMaker Inc a fool.

[genevieve charbon]

>Lee

I deleted fiels to trim the fat of my 5 year solution, triming it to 460 fields out of 960 !

[Ender]

With changing business needs, adding and deleting fields is not unusual (usually adding). Personally, I don't like the idea of keeping unused fields around--I make sure I get rid of them as soon as I know they're not needed.

Of course, it's a good practice to refer to a DDR or similar utility to make sure the references to the field are cleaned up too. But as you noted, this doesn't help with the import mapping problem. Believe me, I'd love to see that improved.

Regarding the idea to use the FieldID: I'm guessing the reason it maps by creation order is because the source file may or may not be a FileMaker file. If it's not a FileMaker file, then the source fields won't have an ID. Maybe FileMaker could rig the import to map by FieldID when the source is a FileMaker file, otherwise use their relative position or creation order. I don't know enough about the nitty gritty to know if this makes sense, or what kinds of implications this would have on existing solutions.

Another Import problem I noted some time ago is that the import mapping changes depending on whether the current user has view access to a source field higher up in the creation order. Even if the Import is scripted, the restored Import order will shift.