Testing for new record in WINDOWS ARev 3.12 (AREV Specific)
At 25 JUL 1999 04:28:47PM Warren wrote:
Okay, a client has a pre-save hook on a Window. The idea is to audit changes on a data file:
When WC_OREC%='; log as new record/add.
When WC_DELETE_REC% is true; log as delete.
Case 1; treat as change, compare all fields between WC_OREC% and @RECORD and log each before and after value.
The problem is once and a great while a new record seems to get logged as a change - no add entry gets logged - from the logic it would appear that WC_OREC% is getting filled with something in a new record situation yet nothing gets stored in the before/after portion of the log record.
I've gone through all the prompt hooks in the WINDOW and all the symbolics that is is using to see if anything might be manipulating WC_OREC% but found nothing.
Any ideas?
I'm adding a save of the raw OREC to another file in hopes of shedding some light on this. Fortunately this is not a high volume file, but any other suggestions would be welcome.
At 25 JUL 1999 05:39PM Jonathan Bird wrote:
Why not put an MFS on the table that monitors changes additions and deletions? Then you wouldn't have to worry about coding each and every window that uses the file, and you would also pick up any "back door" changes via TCL EDIT or such like.
I have an MFS you could try for this if you like.
Jonathan
jb@psiltd.co.nz
At 26 JUL 1999 12:21PM Warren wrote:
I have one myself, as well as the example in the MFS toolkit.
I do not want the additional overhead of an MFS and it is only one table that requires an audit. The subroutines that it uses were developed in-house (not by me) are generic enough that they can be easily plugged into other entry screens.
I proposed a MFS to the powers-that-be and got a flat "No way". Don't bite too hard the hand that feeds you.
At 26 JUL 1999 02:28PM K Gilfilen wrote:
Warren,
What if you change the case statement, explicitely coding the Change as a change, not as the default behavior. Then add a default and code it as an error. I have heartburn about not putting a default in case statements, because then errors masquerade as valid situations and make maintenance harder, (as I believe you are presently experiencing).
And then try to get the coding standards changed…
Kenny