if you have a relationship from A to B called AtoB and a primary key in B, define total_count in B as being a summary = Count Of primaryKey.
In A you can show AtoB::total_Count which is what you're after.
This applies if the AtoB portal is not filtered; If it is, you should duplicate the portal (thus keeping the filtering), making it 1 row height and placing in it the same total_count field which will reflect the filtered total.
You can also create an unstored calculation field in Table B, e.g. total_count = Get ( FoundCount )
AtoB::total_count will equal the number of related records.
In the table which is the parent of the portal records, create the calculation field:
Count ( relatedTABLE::field_PrimaryKey )
change, of course, to be your relationship to the portal as the 'relatedTABLE' and the field to be the unique identifier for each record in that portal.
Count() uses the non-blank values, so if you choose a field that is not blank, then you will know how many related records you will have.
This value will be different for each parent. Because it is a calculation that may change (# of related children), make the field UNSTORED.
I have 2 artists for example.
artist 1 has 20 songs and artist 2 has 6 songs.
When I make calculation field and use total count that field shows 26.
I want to show user each artist have X songs.
post your calculation. you may be using the wrong context again. post a screenshot of your relationship graph.
IN Artists, create a field:
song_count = Count ( Songs::songID )
even if you have a relationship which is a "join" (artists_songs), you will be able to count the Songs.
If you get the wrong count, your relationship may be wrong, or you are trying to base it on the join table occurrence.)
I prefer to NOT have to download files. I prefer screen shots. But others may help from here.
So now what is your suggestion?
Artists::song_count = Count( Songs::ID )
for the number of SONGS
if, however you need the # (by joins):
Artists:track_count = Count(Artists Songs::ID)
(presuming you do have a unique ID for the join).
it's all context (where you are and where you are looking - as in related tables)
So when I count SongID give me all of the numbers.
as I said 26 for example but now I want to have the number of songs each
however thank you very very much for helping.
Go to a layout for Artist Song (the join) make a list view. You can Sort. Add Summary field
As suggested above. Add a part Summarize by (song). Add the summary field in that part. When you sort by artist and song the count should be correct.
BTW, you are asking basic questions covered by the Trainings. Please study them again along with the Help examples.
Sent from miPhone
One level above the current question, as a developer you must also consider the complexity impact you're adding to a solution when you try to satisfy a specific user request.
You must first be able to identify the nice-to-haves from the must-haves, then separate the nice-to-haves into categories, and only implement the ones that somehow add value and / or can be obtained at minimum cost.
In you case, when looking at a CD with 3 performers interpreting 12 songs, showing how many songs each performer interprets is immensely non-relevant (the user can count himself, if really interested) but can add complexity to your data structure. Learn to say "no" to the temptation of "can it be done" if it adds no relevant value.
Just because something CAN be calculated does not mean that it SHOULD be.
Less is more.
Can I use go to last portal row and then count of that? What do you think
Is that true?