Gary,
Another way would be to have a master test set module. That module
would be two tables, a test table and a question table. Each would be
a master set of the test questions. Then when you go to enter a
testee, you would choose a test from the list of tests and it would
copy all the questions for that particular test into a common table of
questions for that person. That way the user could add any number of
test sets to the instrument without creating any more tables.
I would have these tables:
Interface
Child
Test
Question
Master Test
Master Question
. The Test table would basically be a join table between the Child and
the Question table but would still have some data of its own.
. Master Test is mainly a place to create your dynamic list of the
test possibilities
. Master Question is where you create questions to associate with the
Master Test table
This would give you greater flexibility and would normalize your data
better, besides eliminating a lot of tables. All of your questions and
responses would be in one table and would be a lot easier to display.
You could then have a layout where you select a child from a portal to
display a portal of tests that the child has taken. When you select a
test, yet another portal would show you the questions/responses for
that person and test. You could also have it switch to another layout
to give you more room for the test details and results.
If you like this approach, feel free to respond or even email me back-
channel for more clarification.
j.
On Jan 1, 2009, at 1:10 PM, Gary Hunt wrote:
Thanks, Corn, for the reply. I'm not clear about the implications
of your
first paragraph and whether this implies a better way to solve my
problem.
Your other point about the superset table is well taken and which I
considered early on.
This application keeps track of psychiatric test results for children.
There are currently 20 some tests implemented with more possible
later.
Early on I thought about collecting common information in a single
table and
placing the unique information in their own tables for each test with
relations to the common table. However, my problem was that I
didn't know
yet what all the tests where and what would be common. Even if I
knew what
was common between all tests, the same question would come up again
between
different test class-types (mental, hearing, vision, etc.). Hence the
decision to treat each test as separate tables and solve the common
information problem(s) separately as the understanding of
commonality-groupings became apparent.
Does this help?
Thanks,
Gary
-----Original Message-----
From: FileMaker Pro Discussions [mailto:FMPRO-
[email protected]] On
Behalf Of Corn Walker
Sent: Thursday, January 01, 2009 12:50 PM
To: [email protected]
Subject: Re: Copying information from one table to another
On Jan 1, 2009, at 12:36 PM, Gary Hunt wrote:
I still consider myself pretty new at Filemaker. What I really want
to do is create a Union query of similar subsetted information from
about 20 tables. However, I understand Filemaker does not support
"Union" Queries.
It's not the union query FMP doesn't support per se but rather the
dynamic table to contain the results of the query. Depending on your
relational structure you may be able to approximate a union join in
FMP although not dynamic attribute aggregation nor dynamic record
creation.
My first question is "20 subsetted tables?" I'm fairly familiar with
entity types and subtypes and have yet to find a situation where I
would have 20 subtypes for an entity class. Why so many tables?
Second, if these are subsets then that presumes there is or could be a
table for the superset. Why not perform the query there?
Cheers,
-corn
Corn Walker
The Proof Group
http://proofgroup.com/
--
Jonathan Fletcher
FileMaker 9 Certified Developer
Project Foreman
NewMedia Construction Co.
[email protected]
Instigator
The BB&J Network
The "Go-To Guys" for
FileMaker Development in Louisville
[email protected]
