Re: sql to output row as csv string

agree - above powers "selected" it... not they are in a crunch with a
deadline to meet... :)

i really wish i had time to explain the current and the resolution...
perhaps when i am done i will.

I'm almost there...

but the bulky default insert statement with REPLACE used twice on each 306
columns in row
OH and times that by 3...yeah X3, because it puts that row string in 3
different columns in the target table) :)

so as you can see, that trigger procedure is easy to improve on...

first, i will use an rpgle trigger that accepts the before/after image and
SUBMITS that to an another rpg to build these strings to insert into the
target table that gets polled.

Jay

On Thu, Sep 20, 2018 at 3:03 PM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Thu, Sep 20, 2018 at 2:01 PM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

because our non-iseries people used a open source data replication tool
that placed sql triggers on our files that run incredibly long.
I'm refactoring that trigger but the end product is to output a string of
the before/after row in a csv string format.
that row is to be inserted into another table that is polled by the
off-platform process and pull the data off platform...

Are you saying the off-platform process is polling a table, and
expecting that table to contain a column which contains a CSV string,
and parsing that string to get the data?

so before we go off re-designing the process... this is what we are stuck
with

The off-platform process is already built and already expecting the CSV
string?

Am I understanding correctly that the existing very-long-running
trigger already produces the desired output, just too slowly? If so,
how is it doing it now? How are you going to improve on it?

The choice of CSV *string* (not file!) as a transport format is
fascinating to me. I can understand not wanting (or perhaps not being
able) to change the off-platform process. But I feel better choices
could have been made.

For example, the latest versions of Db2 for i have JSON-handling
capabilities. If designed from the ground up with JSON in mind, it
probably would have been easier on both ends.

As it stands, I'm still kind of skeptical that the off-platform
process couldn't be changed (and improved).

John
--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD