I don't want to use portals as I only want the total number not the actual records.
Yet a one row portal can, in some cases, show a summary value for the set of records what would be visible in that portal if it had more rows and a scroll bar.
That may not be the best option here, but it is one option available.
What is not clear to me is what is meant by "work load". Is that the number of records in cases for a given specified set of criteria or is it a more complex computation from data in cases?
"Year", "age", "Gender" and "Race" are all fields in which table? Population? Cases? Both?
(I don't know how to reply to a specific post? If its so)
You know... I didn't think about using a single portal row (oddly cause I did that in another database) I will try that and see what happens.
The actual 'workload' is the count of cases returned by that search (where as population is a sum of the populations). So I was using a global field to hold the FoundCount in but I wanted it to be dynamic like the rest of the data so I was trying to find a new way, but I guess I'm okay with being less fancy :p.
I attached the design for you. The hearingTypes and Resons aren't in use right now but may be later which is why they are there, I am currently just working with the Population, Counties, and Cases. (Yes I realize the population table also has countyNames, when this was originally made it was JUST the population table and I just added all these new tabled on Friday so I haven't yet gone through and switched Population::countName for the County::countyName I will though!)
Thanks for your quick reply.
I got it working.. Thank you so much PhilModJunk :D can't belive I didn't think of such a simple solution!