× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi,

I'm pretty sure, that there is no certain solution using SQL without commitment control / journaling.

Well, it really puzzles me, and I really don't want to give in, but native RPG I/O seems to be the only solution. I don't like it, but I would suggest to change the INSERT statement to a RPG native WRITE operation and setting up an INFDS for that file.

Inside the INFDS you can find the RRN of the written record:

dcl-ds dsInfo qualified;
//...
db_rrn int(10) pos(397);
//...
end-ds;

After the write operation you have to store the dsInfo.db_rrn value of that record, and the you can delete it later using SQL

exec sql delete from ... where rrn(...) = :dsInfo.db_rrn;

And that's it.

But I really suggest to add an ID column to your table which automatically generates unique id's for each record. Then you can retrieve the generated id after the insert:

exec sql insert into ... ;
exec sql values ( identity_local_val() ) into :id_of_inserted_row;

HTH

Regards,
Daniel

Am 16.05.2022 um 18:39 schrieb Brian Parkins <goodprophet.bp@xxxxxxxxx>:

This is a wild suggestion that will probably be of no help at all.

Would a (physical) file trigger offer a solution? (Whether External or SQL.) You could use CHGPFTRG or ALTER TRIGGER to enable/disable as required. The Trigger Buffer would contain the RRN of the successful insert/after.

HTH,
Brian.

On 16/05/2022 17:03, Greg Wilburn wrote:
X2. If anyone knows how to get the RRN for certain, that would solve my issue.

The legacy ERP does not have ANYTHING journaled... the transaction files do not have a unique key on the PF or LF.

I understand what everyone is saying about journaling. No convincing needed. But I cannot simply "turn it on" and risk messages all over the given all the other programs that touch this file.

I'm also concerned about service program procedures (in the same module even) that have COMMIT=*NONE. I'm not sure how to handle that.

If I was certain I could turn journaling on for this file, without creating a host of other issues, I would.

Open to suggestions

--
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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.