RE: Fastest way to get a unique identifier/tracking column changes

Hi Reeve,

As I am using journalling I must address this crimp.
Surely when a user wants to know what changes have happened to this
customer or this product this does not equate to what changes have
happened to a row in a table.  Is this a case of the classic childs swing
'what the user really wanted' vs
'what the engineer designed'  vs
'what was actually built'
If I cannot address the 'really wanted' issues with journals then I
must reconsider.  Even if the 'primary key' changes in a record
'God forbid' I believe I will be able to track this with sufficient
rigor using journals.  Issues such as a programmer or operater deleting
revceivers can be readily address using object security.
What am I missing.

Frank Kolmann

>date: Mon, 12 Jul 2004 15:12:19 -0400
>from: "Reeve" <news@xxxxxxxxxx>
>
>Note on using journals: Table/member/RRN is an inspired thought (even
>though I don't use multi-member files for mission-critical functions), but
>there are still a lot of programmers and operations managers determined to
>reorganize files whenever possible (i.e. you're not looking).  If V5R3
>reorg-while-active physically changes the RRN (which I assume it does),
>that puts a crimp in the journal receiver solution.
>
>-rf