Log edits without showing username/timestamp

I have a table that I want to track several field changes. To accomplish this, I created a change table and add a child record to the main record each time one of those fields change.

James, I would recommend the same thing that Gil did.  Create a child table to log the edits and use the action you created to add to that table.

Thanks, can this be explain a little more? I don't quite follow how this works. How is this preventing the user and time stamp from being added to the log field?

What's the reason you don't want the User/Timestamp?

Because I want to log the record, not who changed it. Who changed it isn't important. And I'd like to  parse other data out of the log field which is hard to do when it's covered in usernames and time stamps.

I've hit a new snag which I'd love some help with if someone can.

I figured out what was being suggested above to log old entries. I have created a new table and the Action is now creating a new record into this new table any time the "Related Job" field in another table is modified. This helps me log any time "Related Job" is modified.

However here's where it's got a bit tricky. What I really want this to do is log every entry made into "Related Job", including it's current entry, as a new record but how do I do that?

The issue I'm having is that simply instructing the Action to "copy the old value" means that only the older entries are copied. The new one is not copied. If I add a second Action to copy the current entry, what happens is that it's now copying the new and old entries every time "Related Job" is modified, causing there to be duplicate entries because the current and old entries can sometimes be the same record.

I don't know if this is making any sense. In short, I want to log every record that is added to "Related Job" as a new record in a new table, including it's current entry, but only if that field gets modified.

James, can you take a step back and explain in plain English what your objective is?  I think that we got lost in the weeds trying to answer your technical questions and lost site of what you are actually trying to do from a business perspective.

Yes, sorry. I got a little carried away. :)

I work in a fashion photo studio. We produce thousands of images a day. Our QB app tracks the movement of each of these images through a series of post production processes. Each image (or ShotID) is assigned a JobID to provide information about when and where the image was taken. Many ShotID's can have one JobID.

If an image is ever reshot, for example to update a garment, the ShotID remains the same (as the key field) and what happens in the app currently is that the JobID for the existing ShotID is replaced with the new one.

What I'd like to start doing is track how often an image gets reshot, because I suspect it is more than a couple of times. To do this, my idea was that if a ShotID has its JobID modified the JobID would get saved to a new field or maybe even a new table. The intention being that I would then be able to say, "this image has had 3 different JobID's and has therefore been shot 3 times".

I am close to this. I have created a new table call "Reshoot". If a ShotID has its JobID modified, an Action creates a new record in Reshoot of the ShotID and the old JobID before it was modified (by using "Copy the old value from JobID"). This works great for saving every old JobID because it will continue to create new records in Reshoot every time the JobID is modified.

However, there's one bit its not doing and I'm completely stuck on. In order to be able to say "this image has been shot 3 times" I need to know in the Reshoot table what the current ShotID's JobID is as well as the other 2 old JobID's. That's the part I need help with. I want these added as a separate record as well, but if I create an Action to do it, every time the JobID is modified it is creating new records with the new and old JobID.

I'm not understanding or maybe there is a KISS answer.

Is Reshoot a child to the Image table? If so, can't you simply make a summary count on the relationship to count the # of Reshoot records?

If that is the answer,  and all you need to do is to create that Relationship, just remember to have the Action also update the field on Reshoots for [Related Image]

Yeah this is really hard to describe. Correct, the Reshoot table is a child of the Shots table.

What is happening is this, as an example:

1. In the Shots table I have a ShotID called  1306426_alternate1.tif which has a JobID of  06072017_NYS5_UNREC_W_1806.
2. If this ShotID has the JobID modified I want two new records in Reshoot created.
   A record of the ShotID (1306426_alternate1.tif) and the old JobID (06072017_NYS5_UNREC_W_1806)
   A second new record of the ShotID and it's new, modified JobID ( 12242017_NYS5_UNREC_W_1806).
3. I can do this pretty easily with an Action. This leaves me with 2 new records in Rehoot for this ShotID because it's been shot twice. Perfect.
4. Here's the problem: If this ShotID is modified again, the Action is going to add two new records again. It will add a record for what is now the the old JobID ( 12242017_NYS5_UNREC_W_1806) and another for the new JobID ( 02022018_NYS5_UNREC_W_1806).
   Problem is, what is now considered the old JobID (12242017_NYS5_UNREC_W_1806) has already been added once before when it was considered the new JobID.
   
   

Basically I want 2 records created upon the first modification of JobID (to log the original JobID and the new one) and then every subsequent modification should only get one new record created (the new, modified JobID). If I leave the Action as it is now, the JobID's start to overlap.

06072017_NYS5_UNREC_W_1806 (original)
12242017_NYS5_UNREC_W_1806 (new)
12242017_NYS5_UNREC_W_1806 (now considered "old")
02022018_NYS5_UNREC_W_1806 (new)
02022018_NYS5_UNREC_W_1806 (now considered "old")
07122018_NYS5_UNREC_W_1806 (new)

This is not something I have been able to work out. I've tried to add the JobID's to a ShotID as new fields instead of entirely new records but that doesn't really work either. The bottom line is, how do I handle that a JobID can be considered old and new at different times?

It's so confusing. If anyone is able to make sense of this you're my hero.