A couple of things...housekeeping first.
You are using ProjectName as your linking field. Keep the field, but link by an autoentered serial# that no one sees...it's more robust. That way if the boss wants to change the project name partway though, it won't cause you headaches.
A field is created in TableB when you put data into a field in TableB through the relationship. On a layout based on TableA, you would have a field or fields from TableB. When any of those fields gets data entered in, it will THEN create the record in TableB.
If you will have multiple records in TableB related to the one record in TableA, a portal would be a good idea. A portal is a way of showing the fields of multiple records from Table B on a layout based on TableA. When you enter data into the bottom blank line of the portal (ie. into a field from TableB showing on your layout based on TableA) it will THEN create a record in Table B.
If you haven't checked "Allow creation of records...", there will be no blank portal line on the bottom to type into and no new record would get created in TableB.
To reiterate, it isn't the entering of data into the TableA key field that creates a record in TableB...it's the entering of data into any field in TableB that is showing on your layout based on TableA (portal or otherwise).
Does this answer the confusion???
Allowing creation of record in TableB will create a record when something is entered in a field in TableB such as when its on a layout based on a TO of TableA.
IOW, place a field from table B on layout of table A and you will see that it will create the record. If you want to have many related records in Table B, use a portal.
*Edit - Didnt see prev post
Ninja and Mr. Vodka,
Thanks for your replies!
I am still, however, a bit confused. Again, filemaker is very new to me.
I am just trying to have one record from Table B linked to another record from Table A rather than multiple records from Table B to one record in Table A. It seems that I should not go the portal route from what you have written.
"A field is created in TableB when you put data into a field in TableB through the relationship. On a layout based on TableA, you would have a field or fields from TableB. When any of those fields gets data entered in, it will THEN create the record in TableB.... To reiterate, it isn't the entering of data into the TableA key field that creates a record in TableB...it's the entering of data into any field in TableB that is showing on your layout based on TableA (portal or otherwise)."
I'm not sure what you mean by, "on a layout based on Table A, you would have a field from Table B." How can I get a field from Table B showing on my layout on Table A? I know that this is a simple question/problem by Filemaker standards but I need more guidance.
Usually, it works like this: you have a table of Projects. Each project can have any number of documents associated with it.
To show the documents associated with the project, you can place a portal to the Documents table on a layout of Projects.
It may be convenient to create new records in the Documents table automatically, just by entering data into the next available row of the portal - that's what the option in the definition of the relationship does.
If there can be only one document associated with a project, there's little need for a separate Documents table.
It is not that only one document is related to each project but that there is only one list of documents related to each project. Each record in table B would contain a list of documents.
If you are sure you don't want to create a separate record for each document (are you?), then you can place the list in a field of Projects and be done with it.
If there will only ever be one record in TableB that is related to one record in TableA...what is the point of having two tables at all??? Just have TableA and include a field in TableA with the list of documents.
One main benefit of having related tables is so that you can have 347 records in TableB that are all related to the same record in TableA.
347 documents all related to the same project...TableA has the project record, TableB has one record for each associated document. The "list" of documents would show up through a portal from TableB on a layout based on TableA.
Now when you want to figure out what project Document 123 is related to, you search the portal field for "Document123" and the correct project is found. Having each document in a separate record in TableB can often be of advantage...but it depends on the needs of your situation.
If you want to find out how many permit filings were made to Montgomery County this year...search TableB for permit filings to Montgomery County and a date range of 1/1/10 to 12/31/10. It's easier to mine the data like that (if you'd want to do something like that) with the separate records in a related table rather than a list in a single field.
Anyway, not trying to sell you...just hoping to have you make good decisions.