I have a DD to populate the Change Log for the Part Table. I have a condition block to monitor 9 fields.
Add your vote!
Get’s my vote for this one.
why not using RowMod.Added() ?
@A.Baeisa - I don’t follow.
Is that a condition I can set in a DD Condition widget? If so which of these:
Or was that a method of a BO? If so, there is no ChangeLog widget in a BPM. I’d have to write custom code to add to that table, and I’d rather not.
My change log directives always have one condition Company <> “” then everything else is done in the change log widget block. That would include created date/time
So in this method, the DD fires on every change to a Part record, and the ChangeLog widget records only the fields that have changed?
Just curious, why even have the condition? Why not just have the ChangeLog tied right to the Start block?
I think maybe just habit from 9.05. You HAD to have a condition in 905 dunno if you do anymore. The result is this in the change log
Nice.
So the ChangeLog widget only creates entries for changes to the ticked-off fields?
If I have PrdoGrp and ClassID ticked-off in the CL widget, and only one changes, then only that one is recorded? Or is the value of every ticked-off field recorded, and only the ones that change have a “from -> to” entry?
yes.
Background -
So we need to know WHO and WHEN the part was created in the Part master.
EDIT: In addition to logging new records, log the changes to about a dozen fields.
All our Change Log widgets come straight from the start block and we do get Added records in there, but something always changes at the same time so I was assuming that was the difference. It hadn’t occurred to me to put a condition in.
it can be done by both DD and MD, put let stick with DD as you trying to do:
i have just used the rowmod (Added) linked to any field -in this case PartNum-, to trigger my BPM as:
Just to wrap this up … It appears that change log records remain, even after the record is deleted. You can only see them with the change log viewer if you re create it. Here’s a part I:
Or you can create two UD fields on the relevant table, then use DD trigered the same way but this time set field value as:
Client.UserID
Current.DateTime
then you can create BAQ/Dashbord, and call this date and filter it the way you want, it is entirely up to you
if you conditioen this DD BPM as i explained it should only add new part to ChangeLog,
i have done many changes to my part, and as you can see only one change added
At least for Part, since 10.2.100 these are being populated (but not displayed):
The other fields, you’ll have to use @A.Baeisa’s solution.
Mark W.
Just curious… But when a field is added to a table, and it is mandatory (like CreatedOn), what value does that field get set to on records that pre-dated the addition of the field?
In this case, do they get set to the date the table was updated(when the new fields were added)? Or possible set to an obvious value like “01-01-1900” ?
Calvin,
Don’t know the answer to that but it does look like it has been tracking the creation date / User since at least 10.1.600.6. We went live Dec of last year on 10.1.600.6 and upgraded to 10.2.200.7 in July and have all the data from the migration parts created on 12/1 and creation dates on all new parts since then.
@ckrusen
this issue is called, historical data update, unfortunately, you need to deal with them separately, i.e. if you are keeping the data somewhere, then you can you use Updatable BAQ/Dashboard or DMT to update these UD fields, this is what i had to do when i create a UD filed in PartRev to store the FAIR Date as we keep this information in spread sheet, if you do not, then it will be null/blank.
