Yikes! What I mean is: I've got a many-to-one relationship, in this
case say the _one_ is the Title of a comic book, and the _many_ are the
Issues. The Issues record stores the foreign key of the Title record,
and does not duplicate any Titles data.

Comics titles are particularly annoying because they sometimes have the
same name; usually you have to differentiate by a volume number, a
starting date, a format, etc. Titles get rebooted every so often.

So...in my previous implementation (4D), the user could enter an Issue
to an existing Title in a 'new Issue' layout. There was a name field
into which the user could start typing a fragment of the Title name
(like 'Bat')and then Tab. Upon the Tab a new window would be created
which contains all related Title matches in a wildcard search , and
whatever other data from each title record was necessary for the user
to pick the correct title. Once picked, the title's key would get
passed into the Issue's field for that key.

Now while working in FM, I've found a number of features which get me
close to this capabiliity: the auto-completion, the value lists
(combining two fields!), etc. At present I've got a Foreign Key field
that shows the Title names in a drop-down list. The foreign key goes
into the field, and the name is displayed in a noneditable field. Not
the best solution, and not very attractive. I 've got a user-editable
key value (bad) and a noneditable name (not great)

A kind soul sent me an example where you can type the related Title
name directly into a field to get names from the drop-down list. This
one's tables are different in that the foreign key isn't required.
Changing the field options to allow a dropdown with related Title names
(as in the example sent to me) means that the user can actually change
those names, after a name is selected and the related record is
selected. Not good!

It appears that to maintain my table's relationships, and simply have
the foreign key stored, requires that the foreign key be the field that
the user picks from. Since the relationship requires a key, there's no
related Title data available until that key is entered/selected. In the
other person's sample, the field options don't require the key. I'm
pretty sure that I want to maintain the nice schema and find a solution
that's based upon scripting.

This presents a few problems, namely there doesn't seem to be an
obvious way to trigger scripts by typing and tabbing/entering a field.
If I were to open a window with a list, or initiate a search for
matching related records (and admittedly I don't know how to do those
things yet) I think I'm forced to use a button. There's some vague
reference to hidden buttons, but so far nothing that seems right.

So if anyone can give me a few pointers, especially in terms of 'how to
think in FM' I'd appreciate it. Also a hint as to what function lets
you search for records based upon a partial string (Lookup doesn't seem
right)!


Thanks
Mike

Portals. Use portals.

You don't say, so I'm assuming FM 7.0 or above.

I'm also assuming that the table occurence Issues is related to the
table occurence Titles by an auto entered serial number that is unique
to each Title record and will never change (but obviously not unique to
each Issue). If that's not the case, make it so. In that relationship
definition, check "Allow creation of records via this relationship" on
the Issues side.

Your user needs to Find the title, simply by entering Find mode and
searching on the Title field. Find mode in FM supports partial string
searches along with wildcards, etc. You can display the results as
individual records that you need to move between or as a list that can
be view all at once. For simplicity's sake, lets say the former.

Now all you need is a portal on this Title layout showing the related
records from Issues. Each line of the portal will show whatever info
you want displayed, IssueNo, Author, Artist, etc. Since you've checked
"Allow creation..." there will be an enterable line below the last with
data.

You can simply fill those boxes out with the relevant information and
you are making a new Issue with the linked TitleId. You need never
display the TitleId. If you want each Issue record to contain the
title in itself, look into field definitions and Lookups.

G






Mike wrote: