Filter data in a Filemaker 10 portal

I'm pretty sure what you would need to is create separate table occurrences that would show only each type and then bind the different portals to the different TO's accordingly.

A common practice is to create the TO's based on relationships to static, global fields.  For example, you could create a new field in the expenses table called relationship_travel and set it as a global field with the value "travel".  

Then you can create a new table occurrence for the expenses table called expenses_travel and setup the relationship for it where expenses::relationship_travel = expenses_travel::type.

This should give you nothing but travel records in the expenses_travel table occurrence, which could then be bound to a portal that you wanted nothing but travel records to show up in.

Then you'd repeat the process for the other two types.

Thanks for the info. Our database is built on an old version of Filemaker and I understand that we can not update to newer than version 10 with out loosing functionality.
I have created 3 tables, one for each portal and will have to be satisfied with that. I am trying to clean up/streamline the database but not making much progress.

You really shouldn't loose any functionality converting to 11 or 12, especially if you are already at 10. The simplest way to test this is to download the 30-day trial version of 12 and convert the files to FileMaker 12 (.fmp12) format.

The one thing to be aware of whenever you do a version convert in FileMaker is to convert ALL files at once. The simplest way to do this is to select all files to be converted and drag/drop them onto the FileMaker Pro application icon. And you don't need to rename the old files, just skip that step. (If convert multiple files that are related individually, connections such as relationships and script links usually get broken).

Thanks for the advice. Lots of changes going on here. Don't know if we will be keeping Filemaker for the database or not. I am trying to organize it for keeping while someone else will be making the final decision.

If your database was originally pre-FM7 and you have multiple files, each with a single table in it, I've written an EE article on how to consolidate multiple files into a single one, which makes management and future development MUCH easier. There are reasons for using separate files with FM7 and later but they mostly for developers doing high end projects.

See: https://www.experts-exchange.com/Apple/Software/Filemaker_Pro/A_4722-FileMaker-Consolidation-merging-multiple-files.html