Hello there, fellow FM'rs!

In my database, after much blood, sweat and tears (relationships, portals, etc), all the necessary info now appears in the correct table, all that is needed is a snazzy presentation!

I'd love to show the relevant records as a series of pyramidal hierarchies, so one quick glance gives an overview of the whole organization. Each area subdivided into tasks, each task performed by an employee, with name and photo displayed.

These elements are all in my table.

However, Filemaker seems to list multiple records only vertically. A thorough search here in the forums did not find any topics that really address the specific goal at hand.

Hoping The Right Brain is the right place for my post, is there a way to do this, an organizational chart with multiple records?

You would need to employ some serious trickery. For example, you might design a layout with boxes laid out in a tree structure. Each box would contain a one-line portal, each starting at a designated row. Now if you sort your relationship just so... voila: org chart.

That's just off the top of my head, I'm not saying this is *the* way to do it.

Hey thanks, [color:blue]Fitch. I sort of suspected something along those lines. However, your comment of one-line portal, starting at a designated row was the element I needed to start tinkering in the right direction.

It's too bad FM makes this so convoluted, not allowing for more extensive graphic customization of the List View.

EDITED FOR UPDATE: Got it working, the trick for me was to:

1. Create a new Table with just one record (I named it "Report").

2. Create a new ID Field in my Tasks Table, and give all records a value of 1 (one) in that field.

3. Create an identical ID Field in my Report Table, and give the only record a value of 1 (one) also.

4. Do the Relationships thing with the ID Fields.

5. Insert a bunch of Portals in the Report Table, one each for Row 1, Row 2, Row 3, etc, just like you said.

That's it! It seems to be working like a charm. Now to endlessly tweak fonts, sizes and colors.

But before I get down to business, just wanted to share the solution, in case anyone else here is interested in doing something like this.

Edited April 22, 200916 yr by Guest

Thanks for the update. FYI you can achieve the same relationship using the cartesion ("x") join on your existing ID fields. I.e. you don't have to define a "constant" field just for that (although it does have its uses).

FYI you can achieve the same relationship using the cartesian ("x") join on your existing ID fields. I.e. you don't have to define a "constant" field just for that (although it does have its uses).

Interesting but enigmatic, [color:blue]Fitch, please don't tease! Could you please give a quick hint as to which uses those might be?

Stated another way:

1. One advantage of the cartesian join not available with a constant field.

2. Viceversa.

Inquiring minds wanna know! ;)

Not meaning to try and assume what Tom meant here but I read it as him talking about the benefits of having the constant, not necessarily regarding the Cartesian join keys itself.

Although I no longer create a constant field for the purposes of a cartesian join as we had to do prior to FM7, having a constant field of value 1 can still be very valuable in filtering relationships, matching on Boolean criteria, etc.

The only example I can think of where a "constant" would be necessary is when you want to match children with a certain value. But then the constant (on the parent side) would be an unstored calculation.

1. One advantage of the Cartesian join not available with a constant field.

The advantage is simply that you don't need an additional field, you can use your existing primary key fields. Avoiding unneeded indexed fields is A Good Thing.

2. Viceversa.

Recently I was setting up a system with a typical Company>People relationship. The client wants ability to designate one person in a company as Primary Contact. Fine, I set up checkbox for that. Now, how to display related Primary Contact on a company list?

One way is to add another predicate to the relationship:

Company>People

Constant>Primary

HTH.