Using name of current field in field calculation

[NovaChan]

Hello,

I'm trying to use GetValue( list ; num ) in an auto-enter calculation where num equals a number in the field's name.

For example, let's say the following calculation is in a field named log2_data:

Let([

    val = Filter( Left( log2_data; 5 ); "0123456789")

    ];

    GetValue( otherField ; val )  

)

What I want is for this field to get the second value as indicated in the field name, but the current calculation is looking for the contents of the field.

Of course I could just put the field name in quotes, but then I'd lose the flexibility of that text updating itself should the field name change.

Can anyone show me how to make this work? I've tried concatenating the field name between quotes in the Evaluate function, but that hasn't worked yet either.

Thanks in advance for your help,

NovaChan

Edited March 10, 2008 by Guest

[comment]

Can't be done this way - a field doesn't know its own name. Perhaps if you explain the purpose behind this, a simpler solution can be found.

[NovaChan]

Thanks for the reply comment.

It seems slightly odd to me that this isn't possible, though I can see why it wouldn't be a common request. This is what I'm doing:

I was looking at Matt Petrowsky's adaptation of Ray Cologon's SuperLog custom function. Matt made a file that uses one global field to store a list of log entries. Each of these entries has delimited data that is then pulled into relevant fields in the same table. Each field converts the entry into a list and pulls the relevant value for that field.

Each field ends up getting the same auto-enter calculation except that they point to a different value.

I was thinking that, instead of going in and changing the value number in each field calc, it would be easier to just paste in a generic calc and pull the number from my field names. This would make adding/changing the field easier and would provide easy documentation.

All that to say, I was just trying to be clever and will now code each field separately.

[comment]

I should point out first that I haven't watched the video, so I may be missing some vital part. That said, I cannot see the point in putting all log data in one field first, then parsing it out to separate fields. Seems to me the equivalent of putting a needle in a haystack, only to enjoy the thrill of looking for it later.

It seems slightly odd to me that this isn't possible, though I can see why it wouldn't be a common request.

Oh, it is a legitimate request, IMHO - only under different circumstances. Unfortunately, FMI botched it when they tried to fulfill it in version 9 by including the Self function - instead of making the function return the field's name, it returns the field's content.

[NovaChan]

Well, hopefully we'll see it in the next version then. I would certainly use it.

To follow up on the audit logging method, you'd probably be more interested in Ray's original demo file. He posted it as demo 646 on his NightWing site. The gist of it is that he uses one custom function in an auto-enter field to store all changes made to that table. The auto-enter field catches all field changes because the custom function uses them as a parameter. Then the custom function grabs each change and formats it along with a bunch of Get function results.

Changes made by a script need to be addressed separately with this approach, but it's probably the easiest way I've seen to track table modifications including the field values. Still, this method does require the logField data to be moved from its table and parsed out to really become useful, as you've noted.

I'm going to need to find some other threads to better explore the practical implications of audit logging approaches.

[comment]

I am familiar with Ray's technique. I suppose there are many ways to handle the result, but I would tend towards separating the row elements by a tab, then exporting the field to a text file. That is assuming the log only needs to be consulted in case some problem needs to be resolved.

In any case, creating a file out of the log entries requires a scripted action - so IMHO it would be best to put all the logic into the script, rather then splitting it up between the script and auto-entering fields.

[NovaChan]

I see your point about putting the logic all inside the script. On that note, how would you recommend triggering the script?

The file I'm thinking of has three heavy users and very little script-driven data entry. It's also hosted on a server that is currently under a heavy load from other databases.

[comment]

Well, it depends on your actual workflow. One thing, though, seems to be clear: if the log is created in a global field, and your solution is served, then you MUST 'harvest' the log before user signs out, or the data will be lost. So a closing script looks like a natural for this.

BTW, if this is mission-critical for you, you might want to check out the fmDataGuard plugin:

http://www.worldsync.com/fmDataGuard/index.html

I haven't used it myself, but I've heard good things about it, and it seems like a more robust solution. Perhaps other members who have tried it would like to chime in.

[NovaChan]

A closing script certainly sounds like a natural place for storing the log data. My concern with this approach is how to ensure that the closing script runs every time. Are there any precautions that must be made to prevent the user from circumventing the close script (besides from a force quit or hard restart)?

The fmDataGuard product certainly sounds like a robust and easy-to-use solution. I do hope to hear some real-world feedback regarding this product though. I'd like to implement fmDataGuard especially with our larger database, but getting to that point will mean convincing others that it's a reliable and efficient move. Then I'll need to wait until we can actually implement it.

[comment]

Are there any precautions that must be made to prevent the user from circumventing the close script (besides from a force quit or hard restart)?

I am not aware of any. A crash is a real concern, though.

[mr_vodka]

FM Dataguard was probably one of the best investments that I have ever made in regards to 3rd party plugins / software for FileMaker. It saves HOURS of development time and the various ways to track which fields and when is priceless.

Its pretty easy to setup and liek I said fast. I recommend it greatly.