Doing a FIND in a Reptition Field

[adario]

Hi

I don't know if this is the correct manner in which to accomplish this task so any suggestion is welcomed.

We have a [color:red]Repetition Field in which we've listed various accommodations that need to be met for disability students. Each accommodation is sorted by Test, Test/Class, Class, or Campus.

I've executed a FIND and have been able to select accommodations that must be met for TEST or TEST/CLASS, but in the print out all accommodations for that student is listed including Class or Campus if these are as well listed in the [color:red]Repetition Field.

Is there a way to separate out the TEST and/or TEST/CLASS info so that only those two categories print out?

Thanks much

Amy

[Søren Dyhr]

Each accommodation is sorted by Test, Test/Class, Class, or Campus.

Sorting a repeating field without the utilization of a Custom Function is beyond me!

Do you mean categorized, in the 4 types?? Since you have "bleedthrough" in your choises can't you make correct searches before you have split the repeater out in 4 field each having their own single line valuelist to make 4 checkboxes present in the layout!

--sd

[adario]

How do I do that? I'm really new to FileMaker and databases... sorry.

Currently, the ACCOMMODATION, TYPE, and ACCOMMODATION EXPLANATION are listed in a lookup table.

The user selects the ACCOMMODATION(S), a Repetition Field for each student. Then, automatically, the TYPE and EXPLANATION appear in Repetition Fields adjacent to the Accommodation.

When I do a search for TEST TYPES, FileMaker locates all records with TEST TYPES, however, the TYPES in the repetition field for that record appear as well. Is there anyway to sort them out?

Thanks much

Amy

[Søren Dyhr]

Couldn't you upload a file for us to see, it seems you're using terms which the rest of the community here associates with something else.

Are you building your file based on one of the template, following the tool here, if you are, is there a slight excuse to your violation of structural approaches such as relational database principles.

Among which you specificly are violating what could be a clause "one fact per field" and another clause could be put "each data is stored in just one location, never ever twice or more"

--sd

[adario]

Thank you very much for your help. I've attached my db.

Info is entered into the student, disability, course, and test/exam forms. Info from these forms are then used in the "Ltr--Test/Exam Partic" and then sent to the course professor. The letter explains how that student needs to take the test to accommodate his/her disability.

I want to print only the ACCOMMODATIONS that apply to TESTS.

Thanks much for any help you can give.

Amy

[adario]

Sorry... here's the file

amy

DS2.zip

[Søren Dyhr]

Why isn't it portalized info, instead of your massive use of lookups ...and could get rid of a lot of redundant fields!

--sd

[adario]

Some things were used in different calculations --- I know I could still use the portals. There were also complaints about the portals being confusing as, in some cases they show up on the various input forms. I just imported some of the info and it became easier for the operators to use.

tks,

amy

[Søren Dyhr]

There were also complaints about the portals being confusing as, in some cases they show up on the various input forms

Take that Boyce and Codd!! No, normalization of data isn't a measure of conning most into believing data is inaccessible, but instead an urge to make data as agile as possible - as vessels of meaning.

I'm afraid it's down to your layouting skills, if you can't make normalized data work for you and your users. For starters must some kind of untangling of your RD take place, read up on the Achor Bouy concept, your graph is wearing all the signs of a beginners graph, where all the right intentions is crammed into one single web, where the distinction between a ERD and Filemakers RD not is obvious yet.

Next thing to read up upon, is that portals can be cut up, and that the price to pay for sandwiching in an extra layer of tables between the interface as such and the data, is next to none.

Finally should you consider that databases facilitate concise data via reporting, and not by borrowing metaphors from spreadsheets, and deliberate attempts to make it behave as one, with numereorus Summaryfields dealing with one attribute.

No what now are individual fields should be turned individual records instead, with the type/field label as breakervalue and summrized on values. Although you provide elaborate relational linking isn't the data normalized.

--sd

[adario]

I figured it out... yaaa! It works great now.

[Søren Dyhr]

But you are keeping me in suspence here! Have you found a way to search dispite the lack of structure or have you normalized your structure??

--sd