Robert,
My thoughts on the created by/modified by stuff:
1) I moved all this to a single object field. I call it '_meta' and it's on
every table I want to manage.
2) At a minimum the field has:
{"created"; {"name: "", "date": ""},
"modified"; {"name": "", "date": ""}}
3) I wrote a few (I think it's 5) methods to manage it. Mainly:
META_UPDATE(ptr to _meta field) // generally in table trigger code
// figures out the table and trigger event then update _meta
Meta_get_text(object) -> returns a pretty text string of "Created: ...
Modified: ... "
Once I started using this I liked it so much I've converted most of my
projects to it. Having a single method to return the create/mod info string
is a delight. This field is also good for other types of meta data.
Calculation dates are one I use. Could include things like last printed or
whatever. Totally optional.
Keep in mind trigger code always runs on the server regardless of where the
record mod takes place. So client side IP vars are meaningless in a
trigger. Current user is the fastest reliable way to know who the user is.
Avoid trigger operations that do lookups or long verification procedures.
Do that stuff prior to saving if you need it. Trigger code is best when
it's lean and fast.
On Tue, Nov 20, 2018 at 11:59 AM Robert ListMail via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> At a minimum, I just have the simple need of recording “CreatedBy” and
> “ModifiedBy” values (username or ID) for one particular table. I do have
> extra fields already in that table that could be repurposed and I would
> probably add “DateModified” to that. However, that’s three fields used just
> for auditing. When I look back at previous posts I see that some of you are
> tracking (saving audit data for) for tables and even individual fields. So,
> as I have a chance to redesign this DB, I wanted to re-think how this is
> implemented.
>
>
> So, Chip, when you have the need to store the username (or ID) of the user
> that created and/or last modified a key record, do you ever have this data
> in the field of the original record? I’m sure I have seen this more
> commonly where the data is in the original record. I guess to keep things
> normalized, you would use a related table (or a standalone table) where
> each transaction that you want to remember is stored. However, with the
> separate table method I suppose you would have to search this audit table
> every time your detail form is loaded (assuming you want to show who
> created or modified a record) and that each time the record is updated the
> audit table would be getting a new record.
>
> Thoughts about your data audit strategy are appreciated.
>
> Thanks,
>
> Robert
>
> =======================
> Robert Broussard
> Houston, TX
> =======================
>
> > On Aug 26, 2015, at 9:26 AM, Chip Scheide <4d_o...@pghrepository.org>
> wrote, Re: Triggers and error handling:
> >
> > so my triggers tend to look like this:
> > case of
> > (Database event = : (Database event=On Saving New Record Event)
> > trk_Last_Modified (->[Account_Postings]Created_Who)
> > trk_Last_Modified (->[Account_Postings]Modified_Who)
>
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> Archive: http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
> **********************************************************************
--
Kirk Brooks
San Francisco, CA
=======================
*We go vote - they go home*
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
