Why do you need to copy this value? (There are many ways to get this value on demand without storing the value in another table.)
A calculation field, C can be defined to compute Field A + Field B
Then a summary field can be defined to compute the total of Field C.
Then a script can copy the total in this summary field into a variable and then the value in this variable can be copied into the field in the other table, but there may be better/simpler ways to do this depending on what relationships you establish between the two tables--if you really need to do this at all.
I have a clientdb with names, adresses, fields of interest as a category etc. I don't need to count anything.
I need different kinds of lists, b.e.:
- of names + e-mail adresses (Field A + Field B), separated by a comma, in one field in one record, for creating groupmails with gmail. I just looked at the template of FMP 'Email campaign management'. It looks great and I would love to combine it with my contactdb, but I cannot find a method to add multiple email adresses to a group at once. If this is possible then it would be the best solution for me.
- of participants = names + e-mail adresses (Field A + Field B), these lists I want to keep as static lists for mutiple purposes and for my archive/history.
as I said I'm a newby, I do understand the relationshippart between tables, making lay-outs etc., but scripting......only the very simple things without formulas or variables.
Adding value 5 + 5 = 10 and concatenating values "Apple " & "Orange" = "Apple Orange" are two different operations with two different operators.
NameFIeld & ", " & EmailAddressField
might be what you need here, but you don't need to define this as a field, it can be a calculation in your send mail dialog.
PhilModJunk thank you for your advices. I think I understand what you mean......most of the time when i read about this I feel as if i'm reading Arabic ;-)
Trouble is.....I'm very bad with calculations and always trying to avoid them, but I'm sure that it's a much smarter way to work in a db.
No !! The intellectual path you really were seeking was looking for FileMaker simplicity. FileMaker can lead you down long long long roads and weeks months years on the wrong path !!