Unable to do 3-table join with FM
ge
--
-- Terms have courses, and courses have grades.
--
-- The grades are recorded as letter grades. The
-- value of the letter grades can be looked up in a
-- "gradeinfo" table that matches letter grades to
-- numeric values.
--
-- So if a term has 4 courses, I want a total of the 4 grade values.
--
-- In MySQL, I can find this total as follows:
USE test;
CREATE TABLE term
(
id int(5) NOT NULL auto_increment,
term char(5),
PRIMARY KEY (id)
);
INSERT INTO term SET term='one';
INSERT INTO term SET term='two';
CREATE TABLE course
(
id int(5) NOT NULL auto_increment,
grade char(5),
term_id int(5),
PRIMARY KEY (id)
);
INSERT INTO course SET grade='A',term_id='1';
INSERT INTO course SET grade='A',term_id='2';
INSERT INTO course SET grade='A',term_id='1';
INSERT INTO course SET grade='B',term_id='2';
INSERT INTO course SET grade='B',term_id='2';
INSERT INTO course SET grade='C',term_id='1';
INSERT INTO course SET grade='C',term_id='1';
INSERT INTO course SET grade='C',term_id='2';
CREATE TABLE gradeinfo
(
id int(5) NOT NULL auto_increment,
grade char(5),
gradevalue int(4),
PRIMARY KEY (id)
);
INSERT INTO gradeinfo SET grade='A',gradevalue='4';
INSERT INTO gradeinfo SET grade='B',gradevalue='3';
INSERT INTO gradeinfo SET grade='C',gradevalue='2';
-- Now analyze the data:
SELECT
t.term,
c.grade,
g.gradevalue
FROM
term as t LEFT JOIN course as c ON(t.id=c.term_id) LEFT JOIN gradeinfo
as g ON(c.grade=g.grade)
ORDER BY
t.term,
c.grade
;
-- This SELECT statement produces this output (4 grades in each term):
-- +------+-------+------------+
-- | term | grade | gradevalue |
-- +------+-------+------------+
-- | one | A | 4 |
-- | one | A | 4 |
-- | one | C | 2 |
-- | one | C | 2 |
-- | two | A | 4 |
-- | two | B | 3 |
-- | two | B | 3 |
-- | two | C | 2 |
-- +------+-------+------------+
SELECT
t.term,
sum(g.gradevalue) as gradetotal
FROM
term as t LEFT JOIN course as c ON(t.id=c.term_id) LEFT JOIN gradeinfo
as g ON(c.grade=g.grade)
GROUP BY
t.term
;
-- This SELECT statement produces this output,
-- which correctly totals each terms grade values:
-- +------+------------+
-- | term | gradetotal |
-- +------+------------+
-- | one | 12 |
-- | two | 12 |
-- +------+------------+
-- I want to do this with FileMaker.
--
-- I made three tables: term, course and gradeinfo.
-- Course has a foreign key that links to the term's
-- id, and course and gradeinfo are linked by the
-- grade field, which is text.
--
-- If I make a portal in a term layout In a term
-- layout, I have a portal to the course table. Each
-- of the two terms (exactly the same data as the
-- MySQL example) has 4 courses in the portal, and
-- each row of the portal also has
-- gradeinfo::gradevalue. In other words, I can SEE
-- four grade values for each term and add them up by
-- eye. But I cannot figure out how to CALCULATE the
-- grade totals in the FileMaker version because when
-- I calculate the grade value total from the term
-- table, using 'Sum( gradeinfo::gradevalue )", it
-- sees only the distinct values. So instead of
-- calculating 12 points for each term, FileMaker
-- gives me 6 for term 'one' and 9 for term 'two'.
--
-- How do I get the results I want? Is there some
-- tricky TO that I'm not seeing? I suspect that the
-- only way is to use a calculation to store the
-- grade value in each *course* record.
--
-- Thanks for your help.
-- George Entenman
Helpful Harry
"ge" <zab...@gmail.com> wrote:
> -- Bear with me. This is a question about FileMaker.
> --
> -- Terms have courses, and courses have grades.
> --
> -- The grades are recorded as letter grades. The
> -- value of the letter grades can be looked up in a
> -- "gradeinfo" table that matches letter grades to
> -- numeric values.
> --
> -- So if a term has 4 courses, I want a total of the 4 grade
> values.
<snip>
Sorry I don't understand SQL gobble-de-gook. :o)
But if you've got three tables with Relationships something like:
Terms Courses Grades
----- ------- ------
Term Number --> Term Number
Course Number --> Course Number
Grade
Grade Value
Then you can't "double-jump" the relationship from Terms to Grades
since there's is no direct link.
ie. in Terms you can't get the value of
Courses::Grades::Grade Value
The easiest way to get what you want is to define two extra Calculation
fields - one in Terms and one in Grades.
eg.
In Courses:
CoursesTotal {Calculation, Number Result, Unstored}
= Sum(Grades::Grade Value)
In Terms:
TermsTotal {Calculation, Number Result, Unstored}
= Sum(Courses::CoursesTotal)
The first gives you a total of each course's grades in Courses, and the
second gives you a total of each term's course's total in Terms.
There are other ways, but this is the easiest. For example you could
store the Term Number in the Graders table as well and then have a
direct Relationship link from Terms to Grades.
Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
42
helpfu...@nom.de.plume.com says...
>
> Then you can't "double-jump" the relationship from Terms to Grades
> since there's is no direct link.
> ie. in Terms you can't get the value of
> Courses::Grades::Grade Value
er... yes you can, as of FM7...sort of
but the related set through a "double jump" is simply the set of all
records in the childofchild that can be reached by that "double jump".
In SQL terms a portal to a child table of a child table is:
SELECT * from childofchild
where
parent.key = child.fkey and
child.key = childofchild.fkey
Its very useful in its own right, but for better or worse that's not
remotely the same thing as the join you are looking for, because the
child table is only considered in terms of determining if the
childofchild is related, but it doesn't create "copies" of childofchild
in the related set for each time they are related.
> The easiest way to get what you want is to define two extra Calculation
> fields - one in Terms and one in Grades.
> eg.
>
> In Courses:
> CoursesTotal {Calculation, Number Result, Unstored}
> = Sum(Grades::Grade Value)
Actually, simply define:
CourseTotal {Calculation, Number Result, Unstored}
= Grades::Grade Value
The sum isn't necessary becasue courses:grades is an n:1 relationship.
(Each course is only related to one grade value.)
>
> In Terms:
> TermsTotal {Calculation, Number Result, Unstored}
> = Sum(Courses::CoursesTotal)
>
> The first gives you a total of each course's grades in Courses, and the
> second gives you a total of each term's course's total in Terms.
>
> There are other ways, but this is the easiest. For example you could
> store the Term Number in the Graders table as well and then have a
> direct Relationship link from Terms to Grades.
The method Harry describes is indeed the best solution. The calculation
in terms sees all the courses so it accumulates properly, and calc in
courses gets the value you need into the courses.
The SQL equivalent would roughly be a nested query. The outer query sums
the join between terms and an "on the fly" table generated by the inner
query that joins courses to grade_info.
Where the calc field defined in Courses is the 'inner query'.
Not sure if I've explained it well, or just confused the issue... but I
hope that gives you some insight...
-Dave
ge
>but the related set through a "double jump" is simply the set of all
>records in the childofchild that can be reached by that "double jump".
>In SQL terms a portal to a child table of a child table is:
>
>SELECT * from childofchild
>where
> parent.key = child.fkey and
> child.key = childofchild.fkey
Thanks, 42. This has got me thinking, and I don't think that's what
FMP does exactly.
As you know, SQL conceptually creates a cross product - a NEW TABLE -
for equijoins and then uses the WHERE clause to select the desired
rows. So in my example, I've got 2 terms x 8 grades x 3 gradevalues =
48 rows of the cross product.
I think that FileMaker does not create the cross product table.
Instead, it shows us rows of the actual base tables. So, since my
gradeinfo table has only 3 rows, FileMaker can never give me more than
3 gradevalues, no matter how many courses I have in a given term. And
if a term has two 'A' grades, that's too bad: there's only one 'A'
record in the gradeinfo table.
The frustrating thing is that FileMaker can DISPLAY a separate grade
value in each row of a course portal. In other words, I can SEE 4
gradevalues for each of my terms. I just can't get FileMaker to see
them for calculations!!??
And thanks to both you and the ever-helpful Harry for the quick
responses. I was pretty sure that I'd need a calculation to store the
gradevalue in the course table, but that violates my sense of how
relational databases should work. Hmmm.... I notice that you're both
recommending an UNSTORED calculation: I'll try that now!
-- ge
Bill
I've seen the other responses so far in this thread. I would like to
back up conceptually on what you are trying to do.
First, my usual approach to the course grade problem involves three main
tables, Student, Course, and a StudentCourse join table (or
"Registration" table), related to Student and Course by StudentID and
CourseID respectively. The grades are recorded in the StudentCourse
table, and are available to both the Student and Course tables in
portals, and in calculated results. So if I want a grade report for a
student I make a layout in the Student table that gives the individual
course grades in a portal, and the grade average as a calculated value
based on the related StudentCourse records. I can also make a layout in
the StudentCourse table that gives some combination of student and
course information for each record in the StudentCourse table.
You seem to be looking for different information, with no clear
reference to the students, though you are recording what are presumably
individual student grades. I infer that you are trying to do some
analysis of historical trends on grades over a series of terms in the
same course. Is that what you are trying to do?
I would probably approach this by using the Student, Course, and
StudentCourse tables I described above, but including information like
Term and Registration Date in the StudentCourse table, along with the
grade for that student in that course. Then I would include a summary
field for average grade in the StudentCourse table, and make a layout
that shows that summary in a subsummary part when sorted by Term. I
think this would give you what you seem to be looking for.
Of course I would need to have a calculation field in StudentCourse that
derives the numerical grade from the letter grade, but that is
straightforward, using the CASE function. I might likewise calculate the
Term based on the registration date.
Bill Collins
Howard Schlossberg
> -- Bear with me. This is a question about FileMaker.
George--
I unfortunately don't know enough about SQL to help you. But it might
be helpful for you to see this writing from Russ Kohn, a professional
FileMaker developer who also has extensive knowledge with SQL and XML:
Russell Kohn <http://www.chapsoft.com> said:
> FileMaker Pro uses a Relationship Graph to combine aspects of QUERIES and VIEWS, provide one (of several) ways to constrain INSERT and DELETE capabilities, and to encapsulate the default ORDER BY and HAVING conditions between query table aliases.
>
> The graph consists of boxes connected by lines. The boxes represent Aliases to database Tables. The lines between boxes represent a complex object called a "Relationship" which includes various attributes about the way the two connected Aliases are related, and in which they can interact. The Relationship object encapsulates:
>
> 1. The join conditions between the two connected table Aliases
> 2. The insert and delete rules between the two connected table Aliases
> 3. The default ORDER BY and HAVING components between the two connected table Aliases
>
> In FileMaker Pro Relationship Graph parlance, a graph node box is called a Table Occurrence or TO, and the set of connected boxes with the lines between them is called a Table Occurrence Group or TOG. Graphs may consist of an arbitrary number of TOs and TOGs.
>
> A Table Occurrence Group represents the set of all possible Views between the Table Aliases represented in the Group.
>
> Each Layout in FileMaker is statically linked to a a single TO, and each layout includes a set of columns defined by explicit reference to a fully qualified TO in the graph, rather than to the base Table columns. At runtime, the View model represented by the Graph is combined with the current layout's columns and linked TO to dynamically create and execute a specific Query.
>
> This separation and encapsulation of different components of the Query model into different levels of the FileMaker Pro design space is tailored to the Presentation Layer orientation of the FMP product.
Hope that helps...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Professional Solutions, Inc. Los Angeles
FileMaker 8 Certified Developer
Associate Member, FileMaker Solutions Alliance
ge
>Of course I would need to have a calculation field in StudentCourse
>that derives the numerical grade from the letter grade, but that
>is straightforward, using the CASE function. I might likewise
>calculate the Term based on the registration date.
Thanks, Bill. In a way it is exactly this CASE function that I'm
trying to implement in a table. I like tables because users can change
them.
We have a lot of strange grades, and I need to normalize them, decide
whether they change a student's scholarship status, affect their GPA,
etc. There are a lot of "business rules" around each grade. Yes, I
could do all that with a CASE statement, but I want administrators to
be able to modify the "meaning" of grades by checking entries in a
table, without having to modify scripts in FMP.
So you see, for each grade, I want to "look up" things that the
business rules say about them, and, of course, I can (and have)
implemented these lookups as FileMaker lookup fields rather than as
unstored calculations, as I thought I would earlier (I may still change
my mind).
The reason for my original question is twofold: I want to understand
the "relational" model underlying FileMaker, and I wanted to solve an
actual problem that I thought I'd solved nicely with a relation because
I could "SEE" what I wanted in a portal (then I tried to add the values
up).
Howard:
That article by Russell Kohn looks like just what I want. I've figured
out for myself that TOGs represent relational queries, not relations,
but I'd love to read Kohn's full article. I'm not sure I agree with
his assertion that TOGs represent "join conditions between the two
connected table Aliases". This example has convinced me for now that
something "non relational" is going on, at least from a SQL point of
view.
Referring to my original example, instead of totaling the gradevalues
for each term's courses, FileMaker is creating a found set of the
gradeinfo records that are related to each term and totaling their
values. But such found sets - since they're in the 'base table' rather
than in a SQL 'cross product table' - cannot provide the totals I need.
(This is one of those write-only paragraphs that only make send as I
write them, I know!)
Anyway, Howard, is that paper available somewhere?
Thanks to all!
-- ge
Helpful Harry
"ge" <zab...@gmail.com> wrote:
> The frustrating thing is that FileMaker can DISPLAY a separate grade
> value in each row of a course portal. In other words, I can SEE 4
> gradevalues for each of my terms. I just can't get FileMaker to see
> them for calculations!!??
Unless I'm missing something, if the values are displayed in a portal
then you can access them in a calculation via the same relationship.
For example, if the Portal using the CourseRelation Relationship has
four rows that look like this:
Course Name Grade
Course A 2
Course B 3
Course C 2
Course D 1
Then you can total the Grades by simply using a calculation of
Sum(CourseRelation::Grade)
and get a total of 8. You can also use other Aggregate functions like
Max, Min, Average, etc.
To get at the individual Grades data itself (ie. 2, 3, 2 and 1) you
have to use a script and loop through the portal reading the related
field. For example, if you wanted to have the Grades listed in a Text
field as "Grades: 2, 3, 2, 1" would require a script.
ie.
Go To Portal Row [First]
Set Field [TextField, "Grades: "]
Loop
Set Field [TextField, TextField & CourseRelation::Grade & ", "]
Go To Portal Row [Next, Exit After Last]
End Loop
Set Field [TextField, Left(TextField, Length(TextField) - 2]
> And thanks to both you and the ever-helpful Harry for the quick
> responses. I was pretty sure that I'd need a calculation to store the
> gradevalue in the course table, but that violates my sense of how
> relational databases should work. Hmmm.... I notice that you're both
> recommending an UNSTORED calculation: I'll try that now!
By definition a Calculation field based on a related fields can't be
stored anyway - it's just habit that I type it so that it looks the
same as it will in FileMaker's field definitions window. :o)
42
zab...@gmail.com says...
> 42 writes:
> >but the related set through a "double jump" is simply the set of all
> >records in the childofchild that can be reached by that "double jump".
> >In SQL terms a portal to a child table of a child table is:
> >
> >SELECT * from childofchild
> >where
> > parent.key = child.fkey and
> > child.key = childofchild.fkey
>
> Thanks, 42. This has got me thinking, and I don't think that's what
> FMP does exactly.
>
> As you know, SQL conceptually creates a cross product - a NEW TABLE -
> for equijoins and then uses the WHERE clause to select the desired
> rows. So in my example, I've got 2 terms x 8 grades x 3 gradevalues =
> 48 rows of the cross product.
>
> I think that FileMaker does not create the cross product table.
> Instead, it shows us rows of the actual base tables.
Exactly. That's the 'architectural' reason that filemaker doesn't (and
indeed -can't- show duplicates in deep children.
Filemaker simply lacks the whole "view" abstraction. You are always
looking right at the data. There's no generating some arbitrary
composite table on the fly, modifying it, summing it to get a value, and
then discarding it, all without affecting the real data.
To get results in filemaker where that is required and can't be worked
around -- you have to predefine the table schema as a separate table,
and actually import the data into it.
> So, since my
> gradeinfo table has only 3 rows, FileMaker can never give me more than
> 3 gradevalues, no matter how many courses I have in a given term. And
> if a term has two 'A' grades, that's too bad: there's only one 'A'
> record in the gradeinfo table.
Exactly.
>
> The frustrating thing is that FileMaker can DISPLAY a separate grade
> value in each row of a course portal. In other words, I can SEE 4
> gradevalues for each of my terms. I just can't get FileMaker to see
> them for calculations!!??
Pretty much. If you display "grades" on a portal to "courses", you are
really looking at the related courses, and then from there seeing the
first related grade value, but that's being brought over from the
*context* of courses. From the parent table, terms, you are in a
different context, and there's no way to "name" the value you want in
the syntax.
Defining an unstored calculation to bring value in from the deeper
child, essentially gives the field a name you can use to access the
value from the context of the parent terms table.
> And thanks to both you and the ever-helpful Harry for the quick
> responses. I was pretty sure that I'd need a calculation to store the
> gradevalue in the course table, but that violates my sense of how
> relational databases should work.
Unstored calcs in filemaker should not really be considered as part of
the data model. They are better considered as "functions" or "stored
query" attached to a table/record.
> Hmmm.... I notice that you're both
> recommending an UNSTORED calculation: I'll try that now!
Lookups, or stored calculations do exist in the table and, from a
purists point of view denormalize a well designed database. Unstored
calculations are more ephemeral constructs that come into existence only
when needed.
I'm probably pumping to much into the 'philosophy', but you get the
drift :)
42
helpfu...@nom.de.plume.com says...
> In article <1141396653.3...@i40g2000cwc.googlegroups.com>,
> "ge" <zab...@gmail.com> wrote:
>
> > The frustrating thing is that FileMaker can DISPLAY a separate grade
> > value in each row of a course portal. In other words, I can SEE 4
> > gradevalues for each of my terms. I just can't get FileMaker to see
> > them for calculations!!??
>
> Unless I'm missing something, if the values are displayed in a portal
> then you can access them in a calculation via the same relationship.
Unfortunately no, you can't.
I'll put a demo fp7 of the situation online...
here...
http://www.djbventures.com/demo.zip
> For example, if the Portal using the CourseRelation Relationship has
> four rows that look like this:
>
> Course Name Grade
> Course A 2
> Course B 3
> Course C 2
> Course D 1
>
> Then you can total the Grades by simply using a calculation of
>
> Sum(CourseRelation::Grade)
The issue is that grade is not actually a field in courserelation. Its a
field in a child of course. See the demo.
-regards,
Dave
ge
> Unstored calcs in filemaker should not really be considered as part of
> the data model. They are better considered as "functions" or "stored
> query" attached to a table/record.
>
> > Hmmm.... I notice that you're both
> > recommending an UNSTORED calculation: I'll try that now!
>
> Lookups, or stored calculations do exist in the table and, from a
> purists point of view denormalize a well designed database. Unstored
> calculations are more ephemeral constructs that come into existence only
> when needed.
Dang! Guess I'm a purist at heart!! ;-) It actually does help me if I
think of these calcs as functions.
> I'm probably pumping to much into the 'philosophy', but you get the
> drift :)
42 - IMHO, you have chosen an excellently appropriate handle! - I don't
get enough of this kind of 'philosophy': while I don't think I've
learned anything in this discussion that shows me how to DO things
differently in FileMaker, you have definitely helped me THINK about
what FM is doing.
If FileMaker made globals and unstored calcs look less like data and
more like class data and methods, then developers might actually begin
to slip into a more "object-oriented" frame of mind. I try to think of
FM files as objects with methods, etc., and try to pass data in and
out. It's not a very good mapping, but it helps me feel more
'philosophical' when programming in FileMaker!
-- ge
P.S. Those who are having trouble following this discussion should be
sure to download 42's demo file: it VERY CLEARLY explains what I'm
trying to do with FileMaker.
42
zab...@gmail.com says...
>
> If FileMaker made globals and unstored calcs look less like data and
> more like class data and methods, then developers might actually begin
> to slip into a more "object-oriented" frame of mind. I try to think of
> FM files as objects with methods, etc., and try to pass data in and
> out. It's not a very good mapping, but it helps me feel more
> 'philosophical' when programming in FileMaker!
I agree that it might help people coming from SQL, or people with
database theory education -- but would it just confuse people who lacked
it?
Flemaker's target audience has historically been small groups, where the
solution is grown by people who don't really know databases, to let them
get a useful database quickly without knowing sql or having a background
in relational database theory.
-regards,
Dave
ge
>I agree that it might help people coming from SQL, or people with
>database theory education -- but would it just confuse people who lacked
>it?
Good point, 42. I only resorted to SQL to describe how I was thinking
about FM. This discussion has helped me understand FM a whole lot
better by clarifying what relations do NOT do in FM.
As for confusing people,I remember how long it took me to understand
what global fields were for. They "looked" like data because they're
in the table along with names, addresses, etc. But they are a
different sort of animal. What I'm saying, vaguely, I admit, because I
haven't tried to redesign FileMaker! ;-), is that FM might try moving
globals and calculations out of the 'fields' view and into their own
places. A good example is valuelists. I can imagine that valuelists
might just be another kind of data, like calculations, but instead,
they're separate, and I'm glad!. I'm suggesting that if globals and
calculations (stuff that really isn't data) were treated more like
valuelists, then FM would actually be easier to learn.
All my "Object Oriented" comment meant was that I try to modularize my
solutions, minimizing the need for TOs for each function, search, etc.,
and use scripts and paramater passing instead. It's just a way of
approaching FM, not a very specific proposal to modify FM itself.
Thanks again for your most helpful comments!
-- ge
Remi-Noel Menegaux
mention also the usual very handy practice of having in every solution a
separate file or table with one record only that would then have only
regular fields - not globals - that are easy to be accessed through
relationships from any other file-table of the database. These fields
can contain any semi-permanent data, such as Owner characteristics, tax
rates, any field being then used as a value list - say for example a
field named 'Condition' that has 'Good', 'Poor', 'Average', 'To be
replaced', ... separated by a carriage return (paragraph return) - all
in the same layout for easy updating.
Remi-Noel
"ge" <zab...@gmail.com> a écrit dans le message de news:
1141654838.8...@i40g2000cwc.googlegroups.com...
Howard Schlossberg
> As for confusing people,I remember how long it took me to understand
> what global fields were for. They "looked" like data because they're
> in the table along with names, addresses, etc. But they are a
> different sort of animal. What I'm saying, vaguely, I admit, because I
> haven't tried to redesign FileMaker! ;-), is that FM might try moving
> globals and calculations out of the 'fields' view and into their own
> places.
Truth is that with FM8, you might find you can do without global fields
entirely. FM8 introduced global and local variables, which can replace
the use of global fields in about 90% of all circumstances where one
might otherwise use globals. The primary exception is that you cannot
use variables for on-screen display purposes.
ge
> Truth is that with FM8, you might find you can do
> without global fields entirely. FM8 introduced
> global and local variables, which can replace the
> use of global fields in about 90% of all
> circumstances where one might otherwise use
> globals. The primary exception is that you cannot
> use variables for on-screen display purposes.
Thanks, Howard. Believe me, I'm a big user of the new FM8 variables
wherever I can. But they can't be used as links to other tables,
something that I don't know how to do without. At least I don't think
they can be used this way.
And of course, variables can't do calculations.
-----------------
Remi-Noel, I understand your concept of the singleton table. I avoid
them when I can because of the need to relate to them, which makes the
TOGs even more complex. I think I'm going to explore global variables,
which Howard mentioned, to see if they can serve the same purpose.
I'll have to get over my deep distrust of global variables: I think I
can! ;-)
-- ge
Remi-Noel Menegaux
"ge" <zab...@gmail.com> a écrit ...
> Remi-Noel, I understand your concept of the singleton table. I avoid
> them when I can because of the need to relate to them, which makes the
> TOGs even more complex. I think I'm going to explore global
> variables,
> which Howard mentioned, to see if they can serve the same purpose.
> I'll have to get over my deep distrust of global variables: I think I
> can! ;-)
> -- ge
'Globals' are 'local' ie specific to each user session, so their
contents cannot be shared reliably between users, while the singleton
table A will. As for relation to that table A, you know how to do it :
have a 'constant' field (calc) =1 in each table B, C, ... and relate
with it to A. Then from table C for example - with that '1 to 1'
relationship with A - you'll get 'all 'records' of A, ie, as there is in
A only one record, the contents of the field you want. I cant't call
that 'complex'.
Remi-Noel
42
says...
With filemaker 7/8 you don't need to use constant =1 fields, just relate
them with the x-join, on any field you like.
-cheers,
Dave