Yes, there is a way to enter data into, and create new records in the child
file from the parent file, but it won't work if the foreign key is a
calculation (and contributor id is probably not a calc).
In the 'Edit Relationship' page where you set the attributes for the
relationship, enable 'Allow creation of related records', and then use the
portal tool (in Layout mode) to draw a portal on a layout in the parent
file. The portal tool will prompt you for the relationship name, how many
portal rows, and a few checkboxes. These are all easy to change later.
Now place a field, using the field tool, in the portal. You will be prompted
for the name of the field and, usually, the available list of fields will be
drawn from the related file. Put in a field for the dollar amount, and also
the contributor id and name (you'll remove them later-- this is for
In the 'contributions.fp5', make certain the contributor name is defined as
a lookup from the parent file ('contributors.fp5'?), using a 'backwards'
relationship still based on the contributor id.
Now enter a valid (i.e., data type number) value into the amount field in
the portal in contributors. The id and name should auto-enter.
'Allow creation of related records' adds an empty, enterable portal row to
the bottom (always) of the portal; entering a valid value into any field in
the portal will create a new record in the child file with the correct
foreign key. A lookup in the child file based on the same key will execute
at record creation. As you can understand, this function will break
(although the relationship and its portal will still work) if the foreign
key is calculated.
The portal is also the most obvious way to display multiple donations from
the same contributor.
Vashon Island, WA
Associate Member, Filemaker Solutions Alliance
> Oops. Sorry to reply to my own message, but I goofed below and I'd like
> to avert non-productive responses. Below where I speak of successfully
> creating a relationship and displaying a calculated field, I should have
> said "contributions.db" rather than contributors.db. It wouldn't be much
> of a trick to display a calcualted name field on the latter. :-)
> --Jack Love
> > First of all, apologies in advance for the "newbie" aspect of this
> > question, and thanks in advance for all replies anyone might
> > contemplate offering me.
> > I'm an experienced Oracle programmer who was recently asked (by a
> > small non-profit organization) to review and perhaps replace a
> > FileMaker DB with a better Filemaker or other DB. (I'll be doing this
> > on a pro-bono basis.) For reasons most readers here will instantly
> > understand, I did not contemplate replacing FileMaker with Oracle.
> > <smile> Deciding whether Access, 3D or some other PC program might be
> > a better choice is a bit more difficult, however, I ultimately figured
> > that redesigning the existing FM database makes the most sense if I
> > can manage it with a reasonably small time investment.
> > I upgraded their FM program to v6 and began analysing the existing DB.
> > It appears to be completely flat-file with contributions (for example)
> > recorded by FM's "repeating field" capability. Since this hard-codes a
> > 30 contribution limit (if I understand this feature properly), it
> > doesn't seem like a good solution to me.
> > I split the DB into two tables--one for contributor info, and another
> > for contributions. I created a relationship between the two based on
> > contributor ID, and I was pleased to see how easy it was to display
> > the contributor name on the contributors.db layout via a calculated
> > field. The next step was to enable the office staff to enter a
> > contribution in the newly independent contributions table by looking
> > up the name of the contributor in order to find the contributor
> > ID--sort of the reverse of what I had accomplished via the calculated
> > field. As near as I can tell, there is no way to do this via FM's
> > native functionality--so the reason for this message is to make sure
> > that I'm not erring here and perhaps discover commonly used solutions.
> > I can see an "easy" solution here--open the contributor database in a
> > new window and instruct the staff to copy and paste the ID from one DB
> > to the other. I'm guessing that I can also do this programmatically
> > using FM's scripting language.
> > Any help--and perhaps even better a source of sample code, would be
> > deeply appreciated.
> > Thanks again,
> > --Jack Love