Re: SQL Triggers where Production and Test on Same iSeries

[Michael Schutte <mschutte369@xxxxxxxxx>]

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,
>
> 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, instruction
>   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.