Filtering FileMaker Portal Data By Altering Child Key Data

From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

As you probably know by now, you can filter a portal by altering the data in the portal. You can do this one at a time or in a batch. The individual process usually involves changing the data in a record in the portal. This change can affect if the record still shows within the portal and perhaps even affect the sort of the records displayed in the portal. The batch process usually requires running a looping script or a replace command within the child file. Both of these can be very drastic changes to the child file data and shouldn’t be taken too lightly.

The main idea that I want to get across is that you can edit related data to a point that it is no longer related because you edited the matching child key data.

This is an old technique that isn’t used that much anymore. I want to cover it because you might find some merit in it or you may encounter it when you work on a database someone else has created.

The idea is to have two global date field that the user enters their range into. Then a script does a find in the child database, uses the replace command to set the foreign key field and returns to the parent table to show the filtered portal. It works much of the time but has “ at least “ a couple weak points.

First, this method can be slow. If the child file has a lot of records or the network is slow, then you may be waiting a while for it to finish.

Second, this method cannot overcome record locking. Record locking is a multi-user database experience. Two users cannot modify the same record at the same time. So a record that should be in your portal may not appear, because someone else on the network was in that record when you script came to it. You don’t get any kind of error message when this occurs. There are some very band-aid, bungie cord, super glue type of techniques around record locking. However, they are a real pain to implement and can prove unreliable as well.

=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2007 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.