I don't believe it can be done, nor do I think it would be desireable. Can you explain why you would want a new table for a new show (say)? Surely managing the fields and relationships and layouts based upon it would be a huge job of work?
Why is what you are trying to do not achieved by creating a new record in an existing table?
Thank you for your reply. Now that I think about it, it probably would not be the best way to go. For the "show info" in the first screenshot, a new record is simply created in an existing table called "shows". But after that record is created, you are taken to the "cues" layout (seen in the second screenshot) to begin entering cues. A show may consist of several hundred cues. So I would think I would need a new table for each show. I guess I could have one table called "cues" that all the cues from all the shows are stored in, but then sorting would become a nightmare.
Thanks again for your help.
It sounds like you need two tables: Shows and Cues, with the Cues records being child records of the Shows Records. There is no reason for sorting to be a nightmare.
Shows have an Auto-Entered ID number field, Date Created field, Date Modified field
Cues have a ShowID number field which relates the Cue to the Show.
Home > Designing and creating databases > Creating a database > About planning a database
A well-designed database promotes consistent data entry and retrieval, and reduces the existence of duplicate data among the database tables. Relational database tables work together to ensure that the correct data is available when you need it. It’s a good idea to plan a database on paper first.Follow these general steps to plan a database:
Relational Database Design 101 (part 1 of 3): Designing a Flat File Database
Relational Database Design 101 (part 2 of 3)
Relational Database Design 101 (part 3 of 3)
The White Paper for FMP Novices is useful -