Thanks, J. I like this approach a lot. I'll have to think about it more to decide if it would be worthwhile for me to switch the approach this far along in the implementation. It might be.
But for the moment, I'd like to see if there is a simple answer to my table load question. How can I copy a simple subset of fields from one table to another. Two internet sources suggested the IMPORT, but I'm failing to understand how I specify a table as the source. I understand how it can be a file, but how to get from a table in the same database? I'm sure I'm missing something very obvious in this. Thanks, Gary -----Original Message----- From: FileMaker Pro Discussions [mailto:[email protected]] On Behalf Of Jonathan Fletcher Sent: Thursday, January 01, 2009 2:16 PM To: [email protected] Subject: Re: Copying information from one table to another 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]
