|
File journal receiver entries for journal code R are:--
BR - Before-image of record updated for rollback
DL - Record deleted from physical file member
DR - Record deleted for rollback
IL - Increment record limit
PT - Record added to physical file member
PX - Record added directly to physical file member
UB - Before-image of record updated in physical file member
UP - After-image of record updated in physical file member
UR - After-image of record updated for rollback
Each journal entry contains the contents of an entire record/row.
So doesn't tell you what? In your case does it really matter? Aren't
you most concerned with inserts, updates and deletes that actually
change the table? This limits the ones you are interested in DL, PT, PX and UP.
If the journal entry is an insert (PT, PX) you write a record.
If it is an update (UP) you update a record.
or
if your history file is to be more of a log file you write a
new one.
or
if you want to flag the changed data on the update compare the
JE data against what is on file for the last transaction.
If it is a delete (DL) you do whatever it is you want to do.
In addition, you can add several columns to your history table that
tie it back to the program actually making the change.
And if push comes to shove you have a source to rebuild the table
and/or the history table at virtually any point in time.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Schutte
Sent: Wednesday, April 10, 2013 10:32 AM
To: Midrange Systems Technical Discussion
Subject: Re: SQL Triggers where Production and Test on Same iSeries
My experience with journaling is that yeah it tells you who changed
something but doesn't tell you what. Am I wrong about that? It's been a
long time since I looked at journals. The request is to have a
history of what was changed and by who, what and when.
On Wed, Apr 10, 2013 at 11:23 AM, Monnier, Gary
<Gary.Monnier@xxxxxxxxx
wrote:
Michael,instruction
Not to start a religious war but not all things need be SQL based.
Sometimes it is wiser to look at alternatives and leverage a
platform's strengths.
Assuming your history file is for inquiries why not switch to
journaling the file? You can have a program park on the journal and
load your history file. The exit program ("Program to receive
entries" parameter) for the RCVJRNE can be SQL based.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Schutte
Sent: Wednesday, April 10, 2013 6:43 AM
To: Midrange Systems Technical Discussion
Subject: SQL Triggers where Production and Test on Same iSeries
We current have our test environment on the same box as our
production environment. Recently I've created SQL Triggers to
record changes to master files to a history file. When we switch
from production to test we get an error that I haven't been able to figure out how to solve.
Member QTRG000001 already exists in file QTRG000001 in library QTEMP.
SQL system error.
Function check. SQL0901 unmonitored by QDBUDR at statement *N,
X'076C'.--
Failure for device or member ITEMST file ITEMST in library WDLSDATA
CPF5257 I/O error was detected in ITEMST
I know that the issue is that while in production, changes were made
to the ITEMST file, therefore, the trigger was created in QTEMP.
Then when I switch to test and make a change to the ITEMST.
(Obviously, ITEMST is in another library.) That's when I get this
error. To resolve, I just sign off and sign back on again, without
making changes in production, I switch immediately to test and I'm fine.
Anybody have suggestions.
FYI, we do plan on moving test from the production box, however, we
will have the same issue when we do do that (do do ha-ha) . As we
will have an environment where programs, file structures etc match
production on the production box, a Q/A environment and a
development environment (which is basically just Q/A with the developer library).
Thank you.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please
take a moment to review the archives at
http://archive.midrange.com/midrange-l.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
