Why would you want to use a container field? The fields used to define a relationship have to compare values (usally with an =) so you'd have to have identical container fields on both sides of the relationship, so even if that were possible, it wouldn't work for your purpose.
Include a data field in the table where you have your container field storing a signature, then link to that field instead of the container field.
Letters::_fkSignatureID = Signatures::__pkSignatureID
You can then place the Container field containing the signature from Signatures on a layout based on Letters and it will display the signature of the related record. You can set up _fkSignatureID with a value list in order to select a signature for a given Letter record.
I am feeling a bit confused at the moment. To clarify - should I create a field called _id_signature in the same table (Staff) as the container field called signature? (this is my naming convention for primary keys)
Also, should I then go to the letters table, create a field called _id_signature and get it to lookup and copy the field (which field - _id_signature or the container field signature?) from the Staff table?
Do I need to create anything on the relationship graph at all?
Thanks for your help
You need some field in Staff that uniquely identifies each record. Perhaps you already have a staff ID field? If not you should add one. And then your letters table would include a match field that links to it in the relationship. It would not copy any data from Staff. Instead, you would format it with a value list of StaffIDnumbers and names. You'd select a staff record by name, but the value list enters the ID number into the field. Then you add the container field from the Staff table to your letters layout. When you select a staff member in the value list, the signature for that staff member will appear in the container field.
Heres the step by step in setting up the value list:
Open manage | value lists.
Name your value lists and click the "use values from field" option.
Select your ID field from Staff as the first field.
Select a name field from Staff as the second field. (You may need to define a calculation field in Staff that combines first and last names for use with this value list.)
Click Ok until Manage | Value List is dismissed.
You can specify that the value list show only the name field and/or that the be sorted by the name field, but if you do, you must also take steps to ensure that the name field is always unique for each record in staff or any duplicate names will disappear from the value list.
This method works for relatively modest numbers of values in the value list. In cases where the list of values becomes longer than is easy to work with, there are a number of otional approaches that either: reduce the number of values listed, makes the list more user friendly, or replaces the value list with a filtered "selection portal" that's more user friendly.
I do have _id_staff in both the STAFF and LETTERS tables.
I do have an existing matching relationship between these two on both side of the equation.
I tried creating the value list using Manage database, options for field_id_staff under the LETTERS table using the _id_staff and staff name fields. I also tried just creating the value list on the LETTERS layout instead of going through the Manage database option, however both ways end up as below.
I also have a field on the LETTERS layout with _id_staff using the value list and it is working well. I tried placing the container field on the layout of LETTERS, is looking up the signature field from the STAFF table, however it is remaining blank.
This is a standard way to include data from a related table. Do you have a relationship defined linking these two tables? What fields were specified as match fields in that relationship?
A screen shot of Manage | Database | relationships might be helpful.