use contents of field as parameter in function ??

[Guy Weymouth]

I want to use the contents of a field to be used as a parameter in a function.

Field 1: back_current_fields

calculation:

FieldNames ( Get (filename) ; Get (layoutname) )

Result = list of field names in the current file on the current layout separated by carriage returns.

This is the field I want to use in a function parameter...

Field 2: audit_trigger

caclulation:

Case(company_name; key_company_ID;key_company_ID)

This is a modified Case statement without an

[TerenceM]

I think GetField is the function you're looking for, but I suspect it can only return the contents of a single field, so you'll have to use something like:

GetField ( LeftWords ( MiddleValues ( FieldNames ( Get ( filename ) ; Get ( layoutname ) ) ; 1 ; 1 ) ; 999 )

and have separate repetitions of this statement for each of the first three fields. You could write a custom function to concatenate the values of every field on the layout, which would probably accomplish what you're going for. But I'm confused by the statement:

Case(company_name; full_name ; phone_number ; key_company_ID;key_company_ID)

Shouldn't this just return the value of full_name? Do you mean:

Case(company_name OR full_name OR phone_number ; key_company_ID;key_company_ID)

Is there an advantage of this over using an auto-enter modification time field? It seems like it would accomplish the same thing, although I'm not sure what your purpose is.

-Terence

[Guy Weymouth]

I'm using this concept to audit changes to fields. I got the basic idea and an example from the examples forum.

The end point, is I want to have a field which lists the changes made to any field on a given layout.

Case(company_name; full_name ; phone_number ; key_company_ID;key_company_ID)

I got this calculation from the example file. It seems that the Case statement is written in a way so it always errors resulting in the default output of key_company_ID. This means whenever the stated fields are changed, it recalculates, meaning the lookup in the field which contains the audit history is triggered and it all works.

I've acheived the same using:

Evaluate(key_company_ID; [company_name; company_category])

Using either function though means that for each layout I need a separate calculation which covers all the possible fields on a layout. So, I'd like to substitute the equation above with something like this:

Evaluate(key_company_ID; [<<all the fields on this layout>>])

I've attached the example I found, which is a converted FM6 file and I've stripped all the uneccessary fields out. (in fact, no I haven't... how do you attach files?!)

I've tried embedding a GetField function into the Evaluation function but it syntax errors on me. If I embed it into the Case function, it allows me to continue but when I test it, it doesn't work.

There's gotta be a way!

[-Queue-]

I don't think this is possible. The list of fields would have to be included as part of the first Evaluate parameter

Evaluate( key_company_ID & "; [substitute( Substitute( FieldNames( Get(FileName); Get(LayoutName) );

[TerenceM]

I must be missing something here. If the purpose is to update your lookup when any field value on the layout has changed, can't you achieve the same thing with an auto-enter modification time field? It sounds like the original Case function was designed to update key_company_ID when one of the three fields being audited had changed (and don't bother if any other fields had changed). If you now want to update the lookup used for the audit when any field had changed, the good old "If ( ModTime ; key_company_ID ; key_company_ID)" will serve the same purpose.

How you design the audit lookup to cover all fields I don't know -- can you post your example? You need to check off "Preview Reply" in order to attach a file.

-Terence

[transpower]

Widey: I understand your goal is to audit changes to fields. Using FileMaker 7 has a whole section devoted to this topic, pp. 305-310. Take a look at it and see if something there will work for you.

[Guy Weymouth]

Thanks for all the responses. I don't have the manual - if it's on the original CD, then I'll have to wait to get it from work.

One problem with auditing EVERY field anyway is the sheer amount of data you would accumulate. I imagine if you have a field in every table that lists every change to every field, then the data amount would begin to affect performance? I don't know.

On that assumption, it's best to just include the key fields you want to audit into the audit calculation and you're done.