Hi - I'm wondering if there is a way to build a calculation field based on whether or not two fields have matching text.

In brief, I have several fields in which a composer's last name is entered -- these fields related to a layout that lists, vertically, the composers entered... I am hoping that when the same composer is repeated immediately I can leave the second field blank on this list because it is redundant for my purposes to repeat the name again.

I've rooted around in Help but haven't come up with anything yet - can FMP even detect that relationship (matching text)?

Thank you!!!

immediately I can leave the second field blank on this list because it is redundant

Filemaker Pro is an implementation of relational database theory, which means that one of the higher goals is to avoid redundancies in the first place.

But I seems to have a problem to comprehend the fine points in your post. At first sight does it seems like a summary report with the composers name as break field.

Another direction could be a straight forward listview where a selfjoin establishes if the records ID is identical to the related value, which only is the case with first occurance in the creation order ...and by it can you deside to suppress a fields visibility.

But nothing in your post indicates what you know to the inner mechanics of filemaker in the first place.

--sd

Okay - so now I have pictures to assist my explanation - I figure that's the easiest. My knowledge of the inner workings of FMP is minimal by the way. I know enough to have modified and reconstructed this template using calculations at the least, and I have put in about 6-7 hours of DVD tutorial, but that's it. I am on a summer project and need mostly fast results so I am utilizing this forum as a crutch and it has help *immensely* --

Anyway -

Picture 1: The program page, you will see where the composer's name is to be entered. You will see that the composer field for Work 3 is blank, this is because Work 2 AND Work 3's composer is "Britten." For database search purposes, we would like the composer to always be entered, even if it is repeated consecutively, however, we want it NOT to be repeated on...

Picture 2: The insert page, which is basically the back of the CD case.

The current Composer fields are just "Composer 1 Last Name," "Composer 2 Last Name" etc. up to 10 --

-- my first thought was to create new Composer calculation fields that know to be blank if the preceding composer field's text matches its own.

Help?

B)

Well you could very well use both solutions I gave, but there is more urgent matters to observe. Your solution cries out for some relational structure - something like:

Composers--Works-

Because colaborations could occure, or is it only in contemporary music??? If not, then:

Composers-

--sd

Soren's right. Having worked with sound recordings databases in the past, I'll recommend that you go with a granular approach to the system. First off, start with the CD as your focus, because, to be frank, if you try to cope with the ontological issues around musical works, your head will explode. Your primary element will (most likely) be the CD track, of which there can be a hypothetical unlimited number on a CD. So, you might have a CD table (with the album title, the Publisher number etc.). Then, a related table for Tracks (with CD ID, track number, duration, Work ID). Next, a Works table, where you identify composer, work, movement. Here it's a little ugly--ideally, you'd want to create some mechanism that would allow you to describe works in a hierarchical manner. That is, start with Beethoven's Ninth, and then create sub-records for the movements (which get described separately on the CD. But, then, you have to figure out how and where in the hierarchy to connect from a CD to a work, and frankly, that's about where my head explodes. My compromise is to put in the information redundantly, and then figure out how to cut out what I don't want. Granted, the data is duplicated in the works tanble, but you don't have to enter it every time, just the once in the works table.