Avoid Overwriting Valid Fields With Blank Data

[JET]

I'm importing records from a file, and using Update Existing Records with a match fields. I would like to update the existing fields with the incoming values, only if the incoming values are not blank.

That is, suppose a record in a Contact table has content in the Address 2 field. The source file has an updated phone number, but does not have a value in its Address 2 field. I want the phone number to be replaced, but I don't want the Address 2 value to be overwritten with blank data.

Just turning off a field in the import dialog is not a solution, because the fields which are empty in the source table vary from record to record.

It seems to me that this would be a very common need. So I'm trying to verify that there is no simple option I'm missing somewhere that tells FileMaker to update existing data with source data, but only if the source data is not empty.

Thanks,

James

[Søren Dyhr]

It seems to me that this would be a very common need. So I'm trying to verify that there is no simple option I'm missing somewhere that tells FileMaker to update existing data with source data, but only if the source data is not empty.

But it's not a fully structured solution if separate fields containing almost similar types of data, Address1 and Address2 is a wrong way to have a database designed, where the propper way is to break such data out into a related table ...not that it helps much with your problem, but it explains why this deliberatly is ignored as an option in the tool.

As a kind of inspiration, should you consider this approach:

http://previews.filemakermagazine.com/videos/513/DataTagging_full.mov

Further more, try to see if you can get the point in this template:

http://www.filemakerpros.com/Splitting.zip

...so you can modify it to deal with your problem!

--sd

[Fenton]

JET, you are right this is a common need. And unfortunately you're also right that FileMaker does not have an option to ignore blank fields; they will overwrite existing data. This is really the correct behavior, from a database point of view. But it is not usually what you want (though it could be). So, you will have to handle it yourself.

When I had to do something like this, I wrote a script that looked at each field, seeing if it was blank or not, before updating the original. You would need a unique ID to identify each original; but you must have that.

It's slower, yes. But Import Matching is no speed demon either. Use Freeze Window, View As [ Form ] within a Loop to process the found set of the file to import.

Søren, I don't think JET means multiple addresses by Address1, Address2. It's just a 2nd line. One of the few places where something1, something2 is not "bad relational design" -]

[Søren Dyhr]

It's just a 2nd line.

Ah! yes the classic issue...

--sd