Hello all,

I use two FM6 databases to manage my school music program. The first
one is the main DB with all student demographic information,
schedules, field trip info etc. The second is used to keep track of
uniform inventory based on the uniform pieces individual IDs (Dress
01, Jacket 01, Shirt 01 etc.) Each record in that DB is one uniform
piece.

I have made a simple relationship that will associated a piece of
uniform equipment to a student via their ID number so it can be marked
"checked out" to them. Students may have multiple pieces checked out
to them at a given time -- I would like to be able to summarily view
all items checked out to a student on the main database's uniform
management layout.

I am still an FM relationship novice and I'm not quite sure if it is
possible to link one record (Student db) to multiple uniform pieces
(multiple Uniform db records) and display all those links on one
layout. Is this possible?

Thanks,
Brandon

You seem to be typically in the 'n' to 'n' relationship, ie a student may
have many unforms and a uniform can be used by many students. So do create a
'Stud_Unif' file made principally with records having the 2 fields 'Stud_ID'
and 'Unif_IDs', the rest coming from simple relationships between this new
file and theeach of the original two ones. Then you create one record in
'Stud_Unif' file per case.
It's exactly the way regular Invoicing solutions are built.
You come to me directly with a copy of your DB - with dummy examples - so I
can do it for you (at least the skeleton of it).
Remi-Noel

"B. Monse" <brmonse (AT) gmail (DOT) com> a écrit dans le message de news:
1176499115.981109.157950 (AT) b75g20...oglegroups.com...

I have been playing around and it seems to also be possible with the
use of a portal on the student uniform layout.... maybe this is as
effective?

Brandon

On Apr 13, 5:54 pm, "Remi-Noel Menegaux" <rnmenegaux_AT_free.fr>
wrote:

What is a portal if not a view of a file through a particular 'filter' named
relationship ?
Now, if it works for you that way, of course it's fine...
We are talking FMP6 aren't we ?
If I understood you correctly, you made in the 'Uniform' file a relationship
with the 'Students' file based on 'Stud_ID', and there is a reverse
relationship in the 'Student' file based on the 'Unif_ID' link.
Now, if a given 'Unif_ID' is used by many students, where in the 'Uniform'
file do you put all the corresponding 'Stud_ID' ? Without a third file I
have a hard time seing it, unless - which is by all means possible - if I
didn't understood your problem.
Is your 'portal' working the other way around, ie in the 'Student' file do
you have a 'portal' showing all Uniforms used by this particular student ?
Again, and without that third file, bravo, and I'd love you explaining how
you did it.
That's why I proposed you to send me you file for having a look at it. If
you feel so, of course.
You may also describe more precisely how those relationships are built :
with the use of a multiple field with as many lines there are students in
the Uniform file ? And the reverse in the Student file ?
Anyway, the creation of a third file is the usual way to do - easily - the
'n to n' relationship. But maybe you don't need a 'n to n' relationship. If
you don't need it, then I didn't understand your problem or else there are
tricks to do it I don't know of.
Remi-Noel

"B. Monse" <brmonse (AT) gmail (DOT) com> a écrit dans le message de news:
1176503680.891457.149740 (AT) d57g20...oglegroups.com...
I have been playing around and it seems to also be possible with the
use of a portal on the student uniform layout.... maybe this is as
effective?

Brandon

On Apr 13, 5:54 pm, "Remi-Noel Menegaux" <rnmenegaux_AT_free.fr>
wrote:

I agree with Remi-Noel that a link table is the way to go with a many to
many relation. Besides the two ID's you need to create calc fields for any
info you might want to see through a portal. for borth linked tables. Then
you can create a portal to visualise the related data. Since you would be
viewing a calculated field is not possible to add or delete or change the
data directly in the portal. You would have to script that through two
scripts. The first goes to the related record(s) in the link table. The
second goes from the link table to the source table. This would require two
clicks of a button, one in each table or that the first script triggers the
second.

Completely untested!

first script. Put the current ID into a global within the link table. Goto
related record <current only>. fire script in link table

second table would need a relation betwee the global and the third table.

The fired script goes to the related record.

Keep well, Ursus