There is a Runtime released by Filemaker in 2006 for students. Called Campus Productivity Kit, it is no longer referenced on Filemaker.com but can be downloaded from CNET among others. NOTE: it is a FP7 database that is an open and unlocked template, it can be opened or converted by FMP.
It may be helpful in making your design decisions.
Filemaker released a FMP runtime database in 2007 for students called "Campus Productivity Kit" and is available online, notably at CNet
Google "Campus Productivity Kit"
Also Starting Point may be useful for design guidance.
The White Paper for FMP Novices is useful -
Filemaker Free - Listing of free resources -
Filemaker Wikipedia -
Filemaker - Version By Version -
Lynda dot com has Filemaker Videos (portions are free)
YouTube - Filemaker Videos
Soliant TV by SoliantConsultingTV
The UK FileMaker Channel by UKFileMaker
FileMaker, Inc. by filemakerinc
FilemakerAcademy's channel by Filemaker Academy
Free unlocked templates are useful for examining design
Starting Point -
RCC Blog -
A free calendar is available and can be integrated into your database
You can search specific Filemaker sites on this Custom Google Search
Looking at FMP business database demos is useful - some are fully useable
The Excelisys Business Tracker V3.0 -
1) I'm assuming that you mean the list of fields in Manage | database | fields
Option a) You can sort your fields by name alphabetically. If you give all fields that you want to group together the same prefix, they'll group together by name.
Option b) you might split your large table into several smaller tables linked in one to one relationships in order to get a smaller list of fields in each. This option takes quite a bit more design work to pull off.
For either option, the database design report tool found in filemaker advanced could be very useful.
2) The way you phrased your question threw me for a second or two. Tables and Layouts ARE NOT the same thing, but as I understand it you are asking a question based on what I called option b) in my response here. There aren't any huge advantages to splitting a table up into smaller related tables if the relationship between each is one to one. If there's a one to many relationship, such as a list of phone numbers linked to a specific student, then it is a good idea to use a related table.
Did you know that you can create multiple layouts all for the same table, but each with a different sub set of the fields defined and each designed for a different purpose? One layout can be designed for viewing/editing all contact info, another for degree info and so forth. It's also possible to use tab controls to group your fields into useful subgroups where only one such sub group of fields is visible at a time.
"1) I'm assuming that you mean the list of fields in Manage | database | fields"
Yes, that's exactly what I meant. I'll check out the report tool you mention but your naming suggestion might simplify things a bit in the meantime. I'll still have to work with a long list of fields, though, which is cumbersome but maybe there isn't any other way.
"2) Tables and Layouts ARE NOT the same thing... Did you know that you can create multiple layouts all for the same table..."
I know that tables and layouts are different - my current database uses one table and multiple layouts to organize my data but I'm trying to get away from the large field set in the Manage Database view. I was thinking of the one-to-one relationship tables you describe in your response because it's an easy way to organize the different data without having to create a separate layout but wasn't sure if that would be any more efficient than one table/multiple layouts.
In any case, maybe I can do a combination of both.
because it's an easy way to organize the different data without having to create a separate layout
I don't see how splitting your table into severla tables iwth smaller records makes that possible. You'll still need to put the fields on a layout somewhere in order to view and interact with the data in them. Whether you have one table with a large number of fields or several smaller tables linked in one to one relationships will not have any effect on this fact.
Just to illustrate, if you have tableA linked to TableB in a one to one relationship, you can place all the fields from either table on the same layout as long as that layout is based on one of the two tables and they look and function as though they are fields from a single table. The only difference is that you'd have to enable "allow creation of records via this relationship" for which ever of the two tables was not the table on which the layout was based.
Sorry, I hadn't gotten that far into my design and assumed that each time I created a table, a dedicated layout for that table was also created - I see now that the only layout in my database is linked to the main table (with a list of the other tables containing the relational field only). So yes, I will still need to place fields regardless of which method I choose. Knowing this now actually helps with my design decision a bit... Thanks for the clarification.