The first field is a list of values from table1/field1.
You could define a lookup for the two other fields.
However I must say, that your question is not really clear, so there might be other ways.
Either Lookup, as already suggested, or autoenter (which may give you more scope to use, say, a calculated value).
To cleify what I am asking. I have a drop down list that presents a set of values. when I select the value I want, I need that value to populate the field the drop down list is in. I alos need to populate 3 other fields as well. All 4 values can be gotten from the same record select in the drop down list box.
I tried creating a "OnObjectValidate" trigger that sets one on the filed values. But it allways puts a 0 in the filed instead of the value I am looking for.
This is the trigger script syntax:
Set Field [mkt_tactics_new::mkt_tactic_name; mkt_tactics_new::mkt_tactic_name=mkt_crusades::mkt_crusade_name]
Consider the possibility that you don't need to do any of that; but instead need to learn some basics about how relational databases work and how FileMaker layouts work.
Also consider the possibility that it really helps to be much more specific when describing problems you are asking other people to help solve.
Having made th e selection in the drop down, it then becomes possible to display the related data on the layout.
Thank you for your patience with me. I am new to file-maker and I understand that I have a lot to learn about it.
FYI: I have 25 years experiance as an Oracle DBA and I am an expert at database design and Sequal Query Language.
I am working on a windows OS. I am using FileMaker pro 13.0v3. I do not have advanced FMP. I am using a 30 day trial version.
-->>>How should I solve this problem?
Should I use a script executed by a trigger to populate the fileds not populated by the drop down list?
What would the script syntax be?
-->>>I will describe the problem in as clear as I can:
I need to populate four fields on a layout after selecting one value from a drop down list.
The four values come from 4 different columns in the code table the drop down list is selecting records from.
Gender_id Gender Age_group State_born_in
------------- --------- -------------- ------------------
1 Boy1 1 CA
2 Boy2 4 VA
3 Girl1 1 WA
4 Girl2 4 MD
-->Drop down list:
-->Layout fields (maps to the Babies table):
-->If I select Boy2 from the drop down list then I want to populate the layout fields like this:
Gender_id = 2
Gender = Boy2
Age_Group = 4
Sate_born_in = VA
O boy.. literally
1 the state of being male or female (typically used with reference to social and cultural differences rather than biological ones): traditional concepts of gender | [ as modifier ] : gender roles.
So... to understand your database "Gender" should have only male, female....or boy, girl.. or similar.. Also... gender with "CA" and "VA"??
If, however Boy1 is and individual, he could have and attribute "gender" which could be "male" female or whatever.
From your explanation it seems you would like to have a database of "babies".
So in the babies table you would have fields like gender, age, state.
Normally you would have only this one table and for each field create a value list. The gender field would for example have to be "not empty" and have "male, female and intersex (about 1 % of babies have this condition acording to this link http://en.wikipedia.org/wiki/Intersex )
Hope this helps.
1. In your DB you have a Babies table with the fields: ID, Gender, Age, WhereBorn
2. The record with ID 2 is a male, aged 4, born in Virginia.
The issue you are trying to get your head around is how to DISPLAY / COPY (cross out whichever does not apply) those details to, presumably, another table in your DB. Do I understand you correctly?
In true relational database style, if all you want to do is display the related data (ie. the details of the baby whose ID you have entered) then what Bruce said applies: all you need is a dropdown list with the ID as the value to be entered and displaying enough other detail so you can see which baby is which. Once the ID is enteredyou can display the related data just by including fields from the Babies table on your layout.
If, for some reason you have not stated, you actually need to copy the baby data into fields in the other table, then you would set those fields to Lookup or autoenter, as previously mentioned. (But do you really need to do this? Remember the DB adage: don't duplicate data)
The attached sample file might give you a nudge in the right direction.
Another thing, which I guess is what Pierre was touching on: I don't understand what distinction you are trying to make with gender entries like boy1 and boy2, girl1 and girl2. Surely Gender is simply male or female (traditionally at least).
BabiesDEMO.fmp12.zip 67.7 K
And with gender_id 1, 2, 3, 4 etc. This really isn't inspiring any belief in the credibility of your data model.
I guess boy1 and boy2 is to generic. I was just supplying 4 unique values. It could have been ken, bob, Kathy, john but since this is a code table you would not typically have a person's name as a code value. The point is I need to copy information from 4 fields in the lookup table to another table.
I AM AT YOUR SERVICE!
Ken Hughes (Oracle Certified Professional)
Skype ID: hughes.ken1
Experienced, IT Leader, Oracle and Data Governance & Database Design/Administration professional; providing added value to corporate data assets.
image001.jpg 13.6 K
Re: "I guess boy1 and boy2 is to generic. I was just supplying 4 unique values. It could have been ken, bob, Kathy, john"
Now I am really confused about what you are doing. I thought boy1. boy2, etc was bad enough in a field labelled "Gender", but ken, bob, etc? WTF?
Re: "The point is I need to copy information from 4 fields in the lookup table to another table."
You still don't appear to be addressing the question of whether you need to COPY or simply DISPLAY related data.
Confusion. WTF. Yes to all.
amazing? why do we give support to a guy who does not seem to listen and neither poses any questions that are understandable?
and neither poses any questions that are understandable?
Maybe rules of normalization, copy vs display and other humdrum database design topics are something that Masters of Oracle don't bother with …?!