Daniel - thanks for the explaination
Raul - these files are part of the ERP we run... I'd add trigger program, but would need to modify all their source where they create the audit record.
I thought about using native IO in a sub-procedure just to make this easier... but doesn't the file "stay open"? I have avoided native IO in sub-procedures for so long that I don't' recall all the potential issues.
That would make life a lot easier if I could just use native IO.
Buck, thanks for the suggestion. I often manipulate text strings with Notepad++ for things like this.
I wouldn't know how to use your Python script - I'm clueless here. Would like to learn though.
It seems like there isn't way to do this with SQL that's as "easy" as with Native IO...
-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Buck Calabro
Sent: Wednesday, May 10, 2023 2:09 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: RE: SQL Insert question
On 5/10/2023 9:37 AM, Greg Wilburn wrote:
Yes, so the whole point is not having to explicitly specify each column on the insert from ICPRTMIA to AUDIA
ICPRTMIA AUDIA
IACOM# IACOM#
IAPRT# IAPRT#
IA101 IA101
etc... etc..
IAUSRN
IAUSER
IATRND
IATRT
IAPRCF IAPRCF
IAVIAC IAVIAC
IAHCD1 IAHCD1
<end> <end>
The suggestion of a stored procedure was just to abstract and
externalise the action/process of creating an audit record. Putting the
code in a sub-procedure in a service program is an excellent way to do
this. One can use native I/O in a sub-procedure; SQL is not a technical
requirement.
I have cobbled together a Python program that creates a text file of
column names. I pasted it into
https://code.midrange.com/b4b44fc1d8.html
It saves me a bit of typing, and perhaps it will save someone else some
time as well.
--buck
midrange.com
