I have duplicated a template layout .... X12

creating 12 identical pages, each linked to a unique table... for 12 different data entrants

is there a way to auto link all fields on the a new layout to a new table?

or perhaps a way to link multiple fields to a table at the same time

Thanks in advance for any ideas

cheers

Will these 12 data entrants be entering the same type of data? And what is the purpose of your database?

I have duplicated a template layout .... X12

creating 12 identical pages, each linked to a unique table... for 12 different data entrants

is there a way to auto link all fields on the a new layout to a new table?

or perhaps a way to link multiple fields to a table at the same time

Thanks in advance for any ideas

cheers

Yes, with some mucking around by copying the layout fields and renaming the base table... but your design is flawed because there should NOT be duplicate tables, fields and layouts.

yes data is all quite similar ... drop down choices, with slight variance for edited input

the database is designed in support of a development program for young athletes, tracking 5 primary components and their 60 or so separate elements ... recording all aspects of training ... calendars, weekly and daily reporting ... mid and end season group and individual reports

approximately 80 athletes with 12 different coaches inputting data on a daily basis

yes, thank you for your comment

I understand the design should be different, although the tables and layouts are not exactly the same, beginning the same .... eventuating in being similar ... each is tailored to suit some more specific needs

yes data is all quite similar ... drop down choices, with slight variance for edited input

the database is designed in support of a development program for young athletes, tracking 5 primary components and their 60 or so separate elements ... recording all aspects of training ... calendars, weekly and daily reporting ... mid and end season group and individual reports

approximately 80 athletes with 12 different coaches inputting data on a daily basis

yes, thank you for your comment

I understand the design should be different, although the tables and layouts are not exactly the same, beginning the same .... eventuating in being similar ... each is tailored to suit some more specific needs

I suggest a book on database design, which will help you think in entities, and identify the entities pertinent to your solution: people (all persons), roles (athlete, coach), events (training, meetings, sport festivals), types of sports or disciplines (e.g. javelin, short track, long jump etc. etc.). These are just the first things that come to my sports-consumer mind; I guess someone in the field (so to speak) will instantly think of many more.

A very rewarding (and enlightening) approach is sketching your reports on paper, or use an existing one, and try to think about where in your database the data on that report would come from. Then set up join tables where you combine the entities to create new data, in a way which later allows you to almost effortlessly derive new meaning from existing data. Think backwards from the high level of results (new meaning) to arrive at the lower level of the underlying data. Here's an example:

Each report (season, mid-season or otherwise) consists of all Results (entity) for someone (Person, entity) who is an athlete (Role, entity) in one or more specific types of sports, or Disciplines (entity), achieved in competitions or trainings (Events, entity) within a certain time period (date, attribute of Event entity), while being supervised by a coach (Role, entity). “Summarize all results” is a good indicator that “Results” is the table we need for our report, and that is must be able to contain all the entities we listed above. A report in itself is derived meaning which can be reproduced anytime from the persistent data; so it hasn't earned its own table, but merely a layout in Results.

Now you might think that creating tables for Persons, Roles, Disciplines and Events, plus the Results join table which combines records from these tables via foreign keys and in addition has attributes (fields) for date and several result types (width, height, time), looks like a promising first approach - and you would be absolutely right. Creating a report in this data model simply means finding Results records for a given person / all persons / a number of persons during a specified time, and displaying them in a summary layout.

You may have to fine-tune the fields for result types, or find that you need to create another join table to record multiple attempts within an event/training, and calculate the top result within the Results table to make summaries work consistently. Also, there will be questions: does the CoachID belong into results, or can we determine who an athlete's current coach was at the time of the event by matching the event's date with the date in a join table of Athletes and Coaches? Or is this too complicated, or altogether unnecessary? It will take a while until you get it right, but then this is fairly normal (npi). This structure also provides for the possibility (or likelihood?) of athletes who are active not only in one, but several disciplines.

Create some other join tables, like Supervision, which brings together Coaches and Athletes. Using this join table as a filter, you can restrict the athletes a coach can choose from during data entry. Add a date field, and you have solved the cases where athletes switch coaches. Add a DisciplineID, and no athlete wunderkind who excels in multiple disciplines with different coaches will be able to sneak past you.

Think laterally: the separate table for Disciplines lets you create a join table AthletesDisciplines (with attribute date/year/season), allowing you to create current and historical athlete rosters in all, or specific disciplines. Setting up the proper relationships from Discipline to Results lets you generate cross-athlete reports for a given discipline. You can calculate Personal Bests, or Disciplines Bests for the current year or a specified period etc. ppp.

Last example: Take a printed training schedule and think about which data in what combinations you need to produce this schedule from within your FileMaker database. Do you have to create new basic entity tables, or new join tables, or both? Work your way backwards and think in entities, as outlined above.

OK, I hope this has given you some ideas and a wide field to examine. And in case I haven't been clear: please drop your original plan / data structure of 12 almost identical tables. Your athletes and (especially) your coaches will thank you.