Re: How to Undo an SQL Insert -- RPG400-L

Greg, what Charles said.

I can't think of a reason you can't/shouldn't journal an ERP system. The
only potential issue is if you have applications that do wholesale updating
of large master files; then the receivers could get very big very fast.

It is surprising that any vendor wouldn't leverage journaling technology.

I've been using commitment control in my transportation management
system since the days of the System/38 and it's been enormously helpful in
three areas.

When developing complex applications which update multiple files, knowing I
can EXEC SQL ROLLBACK means I don't have to code recovery logic into the
app or develop other programs to undo partial updates. One of my dispatch
applications touches 23 tables (updates/inserts), and while the likelihood
of a program crash, communications failure, or system failure right in the
middle of those updates is low, it's not zero. I believe in coding
defensively (I assume something's going to crash) and commitment control is
the way to eliminate that problem.

Journaling has solved hundreds of user problems for me over the years.
With SQL support for journal receivers, it's easier to use than before.
When a user sees unexpected results, an RPG program looking at before and
after record images points me to the issue. The user swears they entered
"X" and I see "C" in the file...problem isolated; now check the code and/or
the user's typing skills. Also, the right type of receiver-based audit
reports can greatly simplify testing at all stages: you can see what's
happening to the database without having to add extra code to the
application (which we all know never gets taken out and merely contributes
to code bloat). I have a daemon monitoring my journal and it creates a
before-and-after database, on a column-by-column basis, of key fields
changed in my order and customer master; this application has saved my
customers thousands of hours. They type an order number and see the
before-and-after of all changes...and the user that made the change.

My vote is to turn before-and-after journaling on; inserting or deleting a
row only creates one journal entry while changes create a before image and
an after image. Include your master files and transaction (history)
files. Do not include work files (i.e., any files you can quickly and
easily recreate); they'll just add a bit move overhead. You'll need to
figure out a strategy for managing your journal receivers; I run a routine
that changes the receiver every four hours and copies it offline. I
normally keep a couple of generations of receivers in case a restore
operation fails (in which case, you restore the last good backup and apply
your journaled changes).

WRT commitment control, study it first. There are a few things you have to
watch out for, like making sure you always COMMIT or ROLLBACK after a
business transaction.

The top-quality databases have ACID properties; these properties are the
keys to the "transaction" model.
A: Atomic (the entire transaction completes in full or nothing is changed)
C: Consistency (processes touching the database always work correctly and
in the same manner)
I: Isolation (a process can work with the database without considering what
other processes are doing)
D: Durable (once committed, the transaction can't be undone by a system
failure).

Commitment control makes all this work.

\reeve

On Fri, May 13, 2022 at 12:11 PM Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

Unfortunately, the file does not have a unique key or auto-id field, and
it is not currently journaled. It's one of the biggest files on our system
@ 36 million rows. As a transaction file, rows are never deleted (only
inserted).

Some more info
I have never used journaling before (no rollback or commit).
My procedure is inside a service program that updates other files
(COMMIT=*NONE).
This service pgm is used all over the place.

So if I turn on journaling for this file would it journal all
transactions? Or just those from my program? All other programs updating
this file do so via RPG (not SQL).

For now, I have added an extra SQL statement to check for the condition
before attempting to insert - but that only checks for the condition that I
have anticipated.
This will most likely take care of any issue, but...

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Daniel
Gross
Sent: Friday, May 13, 2022 11:45 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: How to Undo an SQL Insert

If your file has a unique key - this is the way to go. If your file has an
auto-id field, you can retrieve the value of the given id after the insert,
and delete the file.

But most probably, commitment control is the way to go - simply roll back
after the insert - and it’s gone. Of course, old programs can use „nc“ and
your program uses „cs“ - it doesn’t hurt.

HTH
Daniel

Von meinem iPhone gesendet

Am 13.05.2022 um 16:25 schrieb Charles Wilt <charles.wilt@xxxxxxxxx>:

Just because your ERP doesn't use commitment control, doesn't mean a
process you've written can't use it.

Unless the file isn't journaled...

You have the data you inserterted, I assume there's a primary or unique

key.

Charles

On Fri, May 13, 2022 at 8:13 AM Greg Wilburn <
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I'm working with a legacy transaction file from our ERP (i.e.
Commit=*none).
My SQLRPGLE service program procedure inserts two records/rows into the
file (they are complementary rows - both are necessary)

If the first insert fails, I simply exit the procedure with an error.

But I'm not sure how to handle the situation where the first insert is
successful, but the second insert fails. If this occurs, I need to

remove

the row I successfully inserted.

Is there some way to capture the exact row I inserted successfully?

Like

maybe the relative record number? Or am I out of luck here.

TIA,
Greg
[Logo]<https://www.totalbizfulfillment.com/> Greg Wilburn
Director of IT
301.895.3792 ext. 1231
301.895.3895 direct
gwilburn@xxxxxxxxxxxxxxxxxxxxxxx<mailto:

gwilburn@xxxxxxxxxxxxxxxxxxxxxxx>

1 Corporate Dr
Grantsville, MD 21536
www.totalbizfulfillment.com<http://www.totalbizfulfillment.com>
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com