Why are portals so hard ?

[airflow]

this must have been asked a thousand times... I wasted my whole day on this.

I have several tables. assembly, use, components, clients, suppliers.

In use, I want to list all the possible assemblies that can be of use for a given location.

In both use and assembly, I have a field called assembly_id, which I use to link the tables.

I insert a portal into use, with this relationship selected, and try to achieve this:

list the assembly name and some related fields from the record all uniquely identified with assembly_ID.

Nothing happens. First I couldn't even select the fields when in browsing mode, even if made a popup menu. then I could display them, but could not get the related fields to show up.

Aaaaaaaagggggh.

I know i ran into similar problems over the years, in earlier versions of filemaker. it's always the same thing. This is so frustrating. Any other feature of filemaker cannot make up for the lost hours of the last years...

[mattlight]

First of all we need to make sure of a couple of things that always mess things up and are overlooked.

The field on the left of a relationship and the field on the right relationship need to be the same field type i.e.: Text. I have not come across too many uses for having different field types in a relationship other than a calculation on one side - but in this case no.

You have a field in the 'Use' table that is a Unique_ID

I don't know what this database is for really but I will use an illustration:

Let's say you a Search criteria field in a 'Sales' table that is used to list in a portal a list of simular type of objects/products from a 'Products' table

In the products table you would have these fields:

product type: Text field

Description

Supplier

Price

etc

etc

In your sales database you would have a search field also = text field

On the search criteria field, you may have a pull down menu or button from a value list

i.e.:

Vegetables

Meat

Poultry

Soup

etc

You may also make the relationship Allow creation of records as well.

What you do once you display the information is up to you - but the illustration is to show what type of data and structure is required for a portal relationship to work to view related information

You could make it even simpler by using the same relationship to simply show related information in a value list pull down menu on the next field which then looks up the rest of the information afterwards. It all depends what you are trying to do once you can view the data.

Hope this helps

[-Queue-]

assembly_id has to have a value in both tables for the relationship to be 'valid'.

[mattlight]

yep

Sales Table::Product_Type (Text) - value list Vegeatables, meat, etc

Products::Product_Type (Text) - result will be Vegetable, meat, etc - automatically entered if creating a new portal record whilst being under one of the selections of the value list in the sales DB

Or, in the Products DB itself, use the SAME value list when adding new records so that it has the right hand side of the relationship defined.

[mattlight]

VegEATables will not find a related record of VegETables - exact would be good - not like my bad spelling a boxing glove approach to typing LOL