Something is missing, but what?

[simoncpage]

Attached is my attempt at making the audit from http://www.nightwing.com.au/FileMaker audit example work.

I have it working fine (and only on one field - Title) EXCEPT I cannot get it to return the From cell value. Has anyone else got knowledge of this set up?

Attached is the original.

Any help would be great

Thanks

Both_Audits.zip

[Lee Smith]

Hi Simon,

I think I understand what you are asking, the file is working as expected. The field starts out as [Null] value as per the calculation, and when an entry is entered, if show the [Null] being changed to whatever the entry is.

For instance, in your file "Test_Audit", your record 3 has no entry for Title, if you change the Title from blank, to Mr. it shows from [Null] to Mr.

HTH

Lee

[simoncpage]

If you look at record 3 it says in the log_txt From -> to : MR -> MR which isnt correct!

Its showing the value now -> the value now

And If I change it to say Mrs I get:

Date: Time: User: Field: From: --> To:

----------------------------------------------------------------------------------------------------

06/07/2004 15:03:57 Simon Title Mrs --> Mrs

06/07/2004 14:12:47 Simon Title Mr --> Mr

not Mr -> Mrs which is how it should be.

[Lee Smith]

I agree with you that there is something not right, if that makes you feel any better.

I have checked all of the calculations, relationships and lookups and they appear to be the same as in Ray's files, obviously we are missing something here. There are differences between the Windows version and the Mac version, which I picked up while trying to duplicate your files from the Mac version.

One of the things I noticed was that Ray made a point in the Mac version of telling the developer that the Field Names needed an extension of a "_" followed by unique numbers such as Title_01, FirstName_02, Surname_03, etc as his calculation parses the data using these extensions.

Another difference revolves around a global field gLogFieldNames_txt in the Win version that is not used in the Mac version.

At this point, maybe Ray can help you out.

Or, you might try using the one of these examples. I prefer Steve Wilmes' approach.

Field Modification Tracker By: Bob Cusick URL:

http://www.fmfiles.com/tnt2.html

Modification Times By: Alberto Diaz-Hermidas URL:

http://www.fmfiles.com/tnt2.html

Tracking Modifications By: Steve Wilmes URL:

http://www.fmfiles.com/tnt2.html

Sorry I wasn't much help to you,

Lee

[simoncpage]

Ray has given me the file back working but said hes a bit busy. Any ideas whats different?

Thanks

Fixed_Audit.zip

[Lee Smith]

The only thing I can spot (remember I'm using a Mac and they are different), is that you put a comma in one of the calculations. I.e.

cLog_Trigger was: IsEmpty(Title), should be without the comma and an "or" in it's place.

IsEmpty(Title) or

Status(CurrentRecordID) , Status(CurrentRecordID))

Copy his calculation for this and the other one and see if that was it.

Lee

[simoncpage]

I already spotted that - thats doesn't make any difference. It still points to and give the RecordID return if its a "," or an "OR" and completes the relationship.

I guess I'll have to wait till Ray gets time to tell me what it is. How annoying been staring at this most of the day! LOL

I assume its not a simple thing as Ray would of said....whatever could it be!

Thanks a bunch for your help Lee!

[Lee Smith]

I guess I'll have to wait till Ray gets time .... - snip -

PLEASE share what he tells you with me, so I can add another flat spot on my Forehead.

Thanks a bunch for your help Lee!

You are welcome. I glad you spotted the "," and "or", That's A GOOD sign, and shows you are learning the ways of FM.

Like I said, I have found the one by Steve Wilmes pretty good, and have used it many time. However, I really want to know what I'm missing here.

Lee

[LaRetta]

It still points to and give the RecordID return if its a "," or an "OR".

Errr, they will produce vastly different results. If we compare only the final lines -

Case(

IsEmpty(InputField_80),

Status(CurrentRecordID), Status(CurrentRecordID))

If ANY field is empty, produce RecordID. Or else (default result not empty), produce RecordID. This trigger needs to fire on every field regardless of its condition.

Case(

IsEmpty(Phone) or

Status(CurrentRecordID) , Status(CurrentRecordID))

If ANY field is empty OR RecordID, produce RecordID. Status(CurrentRecordID) by itself is not an evaluation. If a field isn't empty then what? You don't have a default result to catch those fields that are not empty so it breaks on you. Yep, that comma's pretty important there.

BTW, I use AuditTracker.fp7 in everything. I have tried many others but like this the best.

LaRetta

[LaRetta]

Ooops, this makes no sense to me. I responded according to what you and Lee said about it and my understanding of the process. It works with Case(IsEmpty(field), Status(CurrentRecordID), Status(CurrentRecordID))

I pulled out my old version 6 of AuditTracker and that is also how it was listed, although I hadn't really used it and 7 is quite different. You have 3 demo files and I am confused about what you had/have.

Well, the Case() statement has no default and I think that is why it won't always trigger. But there is more in Heaven and Earth than what I know.

LaRetta

[simoncpage]

Anyway changing to Case(IsEmpty(field), Status(CurrentRecordID), Status(CurrentRecordID)) makes no difference on the outcome I can still only get it to show "new value" - > "new value" (instead of "old value" -> "new value")

The first attachment I added contains my working version (which doesn't work and Rays version which does)

The last attachment was the one that Ray sent back to me which works. Although the problem is he was too busy to explain what he did. So I basically want to know what he changed. (also the case statement that i got back from Ray still have the

Case(

IsEmpty(Phone) or

Status(CurrentRecordID) , Status(CurrentRecordID))

format more evidence its not this.

Lee I will post back when Ray has time to tell. I sent him this thread link so he may well cut in and put us out of our misery!

Thanks

[CobaltSky]

I did send Simon an update of his file, but as he says, did not have time at that point to offer a proper explanation of what I had changed or why. I've now sent him a note of explanation. Here is the gist of it:

The audit technique depends on the behavior of various elements of the application, some of which are somewhat obscure. One of those is that the functionality depends in part on the creation order of fields. Bear with me while I explain...

In FileMaker, lookups are evaluated in the order of their 'tier' in the internal table of dependencies, and then within the same tier, they are evaluated in creation order. In the context of the audit tracking process, in order for the previous field value to be captured successfully it's necessary that the log data be captured to the log text field before the log update field has been refreshed with the new values from the current edit. That means that the fields must be set up to be evaluated in a particular order - namely in reverse sequence, so that the Log_txt lookup will refreshed before the LogUpdate_temp field updates to reflect each data change (or in other words so it will grab the prior-to-change value from the LogUpdate_temp field).

Since the two fields in question both fall within the same tier of FileMaker's table of dependencies, it is necessary for the Log_txt field to have been created before LogUpdate_temp in order to ensure that Log_txt grabs *old* data from LogUpdate_temp. The problem was that in Simon's file the fields had been created in the opposite order, so LogUpdate_temp was being calculated prior to the generation of the Log_txt value and the previous field values were thus being lost.

I was able to correct the problem in the file fairly efficiently by creating a new LogUpdate_temp field and deleting the original one (after updating all the references to it in the NewLog_data calc etc). That way, the LogUpdate field being referenced was moved down in the creation order (and therefore in the relevant tier of the table of dependencies) and the correct field update order was established.

Fairly easy to do, but not so easy to explain...

[simoncpage]

Thanks Ray! I get it now! Appreciate the help from all of you!

[CobaltSky]

...Ray made a point in the Mac version of telling the developer that the Field Names needed an extension of a "_" followed by unique numbers such as Title_01, FirstName_02, Surname_03, etc...

Hi Lee,

As a matter of interest, the versions you mention were both cross-platform. The one with the '_01', '_02' (etc) suffixes was an earlier implementation designed to show a relatively simple a way to track large numbers of fields without cluttering up the table with large numbers of 'tracker' fields. The other file was a minor variation (some would say a refinement) of the technique which was published a little later. It showed a way to achieve the same outcome, while retaining complete flexibility on field naming (ie no longer requiring the field name suffix for parsing).

What distinguishes this technique from the others you mention is that it is able to track eighty - or a hundred and eighty - fields with only a handful of utility fields added to the file. By contrast, earlier methods such as those you've mentioned, required that a tracker field be added for every field being logged, as well as the core set of trigger, calc and lookup fields. So for instance, with the 1997 Wilmes method, if you were to add tracking to a table with 80 input fields to be logged, you'd end up with a table with 165 fields. With the method shown in AuditTracking.fp5 you would require only 86 and with the more recent AuditTracker.fp7 you would require only 82.

Sometimes less is more...