I have a table of around 25000 "Parents" and 11000 "Children". I want to display the Parents (or a foundset thereof) in a List view, each with an indicator (implemented by Conditional Formatting) of whether or not that Parent has any Children.

I placed on the body of the layout a related field Children::Name, and set Conditional Formatting for the field as follows:

Formula: Count(Children::Name) = 0

Format: set fill=red

When I display this layout in Browse mode, it renders VERY SLOWLY - row by row - and puts up a Find-in-progress message between each one. Each row takes about 5 seconds to add to the list. When displaying any significant number of parents, this becomes a real problem. Furthermore, I can find no way to interrupt this, even with User Abort enabled. I actually have to force-quit Filemaker.

Does anyone know what's going on? Am I using the right technique to do what I'm trying to do?

Thanks,

Chap

Not sure what your issue is but you dont have to use Count (). If it is simply checking to see if it has a related child record(s), then a simple not IsEmpty (ChildTO::pkID) should be suffice.

What kind of relationship are you using to the child records?

Not sure what your issue is but you dont have to use Count (). If it is simply checking to see if it has a related child record(s), then a simple not IsEmpty (ChildTO::pkID) should be suffice.

I believe that I also tried 'not IsEmpty(Child::Name)'.

What kind of relationship are you using to the child records?

Something like this: Parent::State = Child::State AND Parent::City = Child::City AND Parent::Zip = Child::Zip.

I'm unable to retrieve the layouts from the "broken" file so I can't remember exactly how I expressed the condition for the Conditional Formatting. But when I removed the field with the conditional formatting from the layout at one point, I didn't have the problem, leading me to suspect the problem lay in my condition.

Oh well, maybe I'll stumble upon it again some time.

Why not just base the relation strictly on Zip?

Why not just base the relation strictly on Zip?

I need to be more careful about my examples - that was a conceptual example rather than the actual one, which would have taken more time to explain. There are three independent fields which, taken together, comprise a unique key for the Parent table. My example was a poor one, since (as you point out) ZIP implies STATE+CITY.

I'm writing a metadata analyzer for databases in a school district. Each school district has multiple schools; each school has a database; each database has many tables, each table has many columns. I need SchoolID + TableName + ColumnName to uniquely identify a column in my domain.

But I'm not concerned about the design here; rather, about the odd performance hit I took with my formula for conditional formatting.