Hi,

I would like to check your opinions on the best method to achieve the following.

- The user fills in field A and the record is committed

- Other fields in the same table needs to be autoentered with information. Generally, the date when field A was filled in, the time when field A was filled in, the user ID, etc.

I know I can easily achieve this with the Set field function, but I have heard that this is not recommended (anyway, I would like to hear your opinions). None of the fields are user modifiable (only via script).

A twist to this question is if the fields to be filled in are in a different table: the record to be modified by the Set field could be in use. Please take into account that I am not creating any new records, just filling in information in existing records.

I was wondering if you use any standard method (automated) for this issue different from a Set field script step.

Thanks

Edited December 19, 200718 yr by Guest

Generally speaking are you not setting data fields but instead references to locations where data exists. Unless you are making a historical tracking, such as invoices where you need a snapshot of the price level at a specific moment for each itemline. Lookups are these called.

Take a look at this:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000717

...and investigate how historical data is distinguished from live related values.

--sd

Generally speaking are you not setting data fields but instead references to locations where data exists...

--sd

Thank you for the input and the link. However, I am not talking about an issue between live data and related data.

Take the following example:

- User fills in field1. Field1 is always entered using a script.

- Field2 (TimeStamp) needs to be automatically entered with the date and time when field1 was filled in.

In this situation, no data needs to be looked up from anywhere else. This is just a TimeStamp field that the user is not aware of, but that I need to set. Could be any other type of data, not just dates or times. Whenever field1 is filled by the user, field2 must be set.

I could complicate things like setting different values according to field1 value, or specifying that field1 is not entered using a script, but I do not need that at the moment.

What I was mentioning was that one of the option to do this is to script it using a Set field step.

Is this the best option or there are better alternatives?

Thanks

Does this provide enough information?

However could this provide some thing similar:

http://www.filemaker.com/help/FunctionsRef-34.html

However is it a heavy thing processor-wise, and you can instead bring in the trigging field by postfixing your calc field with the trigging field this way:

& Case(0;triggerField) ...only beware the "&" makes the result text!

--sd

Yes, I've used the AutoEnter calc with

Evaluate("Get(CurrentHostTimeStamp)";ModifyTime)

That way I get the Host time stamp rather than the client. Pretty silly that isn't an option for the modification time.

In my example above, ModifyTime is a field that has the local time modification. So any time that record changes at all, the Evaluate will trigger.

So, to your question, you could instead have:

Evaluate("Get(CurrentHostTimeStamp)";Field1)

And it would only trigger when Field1 changed. Note that I believe that will only trigger if it is a local field.

But stored values will be seen relations away, you just can't monitor changes in unstored fields a relation or more away, because they have no value until rendered on a layout.

or specifying that field1 is not entered using a script, but I do not need that at the moment.

This seems to be some sort of auditlog, there are plenty of methods to choose from by searching for them here or at JMO's page. But the autoenters could also include a Get(Scriptname) in the calc to tell if the value has been changed by a script or not.

--sd

Bluearrow, good grief it certainly makes it difficult to envision what in the world you are doing when you talk abstract. Surprisingly, we have seen most every possible business scenario here and if we even have a clue as to what and why you are doing what you are doing, we can help you. Otherwise we are just poking a pin at a donkey.

Soren, bless his heart, is giving it a shot but it wouldn't take you any more time to speak it in standard english than FieldA and riddles. We need to understand the purpose and context. You say they are not related and then you say it involves another table and ... I feel like my eyes are crossing trying to picture it. :wink2: