perhaps, this subject has been made before. But I couldnt fınd in  forums. and my brain has stopped for now.please help

 

I have a field "city" named. there are so many records in city field. for example 1 paris, 2 newyork  and 3 istanbul records.I want to see this result in portal thank you so much.

Example.zip

Hi, 

 

Check out this demo on portal filtering.  http://fmforums.com/forum/topic/71836-getting-more-out-of-filtered-portals-in-version-11/

 

:-)

I think I couldnt explain what  my problem is.

 

I want to make a summary in portal within the same table, ıf you examine my Attached File you understant better.

Of course I examined your attached file.  

 

Did you examine the attachment in the link I provided?  There is no difference between relating to another table or to the same table; principle is the same.  

 

What part are you stuck on?  We can help you with it.  

Here is a sample, since it can be easier in your case than the link I provided.  

 

1) Create another table occurrence called Cities 3.

2) Join Cities 2 to Cities 3 on City

3) Portal should be based upon Cities 2 as you have it.

4) Summary count field within the portal must be based upon Cities 3

5) Portal filter should be:  Cities 3::id = Cities 2::id

 

By looking through to another table occurrence, we can isolate the entries in the portal to only one each since Cities 2 can only *see* the first related Cities 3 record.  Then summary from that new table occurrence counts all related.

ExampleMOD.fmp12.zip

thank you LaRetta

I just thought ... you could also use ExecuteSQL() to generate a unique list of counted cities.  It would not produce a portal but you could get a columnar list displayed in a field with a scroll bar - no extra table occurrences needed. 

 

I mention it because filtered portals are resource-intensive if there are a lot of related records and/or if the filter criteria is not static (which this is not).  If this is a customers table with several thousand records, for example then the ExecuteSQL() method might be faster.  And it would decrease graph clutter since two extra table occurrences wouldn't be necessary.