|
Okay John--
Lets turn the heat down somewhat
I never said anything about using SQL to consume XML The XML request
and response is stored in an audit file I am looking for a way to
examine the data to determine which orders have had a certain data
string either in the request XML or the respond XML In certain
situations, I am looking for what was returned by the orders within an
XML tag Just looking for a tool that would be a "nice to have"
That's all
If you don't like the trend - then don't use it Because someone else
wants to try and push the envelope, then good luck to that person.
Don't chastise them for what they are trying to achieve If someone
sees that this tool is available and wants to use it - then good luck
to THAT person
That MY humble opinion, of course
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
John E
Sent: Wednesday, June 18, 2014 9:17 AM
To: Midrange Systems Technical Discussion
Subject: Re: Finding data between XML tags using SQL
I see this trend.... and i don't like it.
Use SQL for all kind of things, just because it's "built into" SQL.
SQL is for data definition and manipulation.
Just because, like many things in IT, SQL is constantly "improved" and
nowadays you can do about "everything" with it, especially compared to
RPG, like all kinds of date checks and manipulations, does not mean you should.
For example, suppose you want an easy way to add work days to a date.
In RPG there is nothing "built-in" for that.
In SQL there is some calendar functionality built-in. Should you use it?
I would - always - prefer to implement it in RPG, in RPGIV that is,
but nicely wrapped up in a procedure in a service program. Maybe
initially it's more time to implement than just add some SQL code and
change the member type to SQLRPGLE (just because of some trivial
functionality, which convolutes the source IMO). Mostly it's quite trivial to implement, IMO.
However, the end result is much more readable: newdate =
AddWorkdaysToDate(olddate).
So, iff you really want to do this with SQL, then put it into a
procedure so the next guy (who maybe is not such an SQL expert to
immediately see what's going on) doesn't have to delve into the SQL
books just to find out what's happening.
Using SQL for these kind of things, like consuming web services for
example, is for one-off things, not for your production code that
needs to be robust and adaptable etc etc. And there will be a time
that that little SQL code snippet which was so handy can't be changed
to support changing needs, and so has to be thrown out as a whole to
be replaced with straight code, which it should have been from the
beginning. There is a whole mechanism that kicks in when you change
RPGLE to SQLRPGLE, just to "quickly" implement some basic functionality.
It's like using the CPYTOIMPF command in production code, what is see
regularly, and then telling the customer "no we can't format the date
that way because CPYTOIMPF doesn't support it". Writing to a CSV file
is trivial. Make a program once, and use it again and again and have
all the flexibility you need now and in the far future. But what i see
in practice is that CPYTOIMPF is used, simply because it "fits" the
requirement at that moment. Until it does not... It's meant for quick
fixes, for us command line jockeys, not to be used in production software.
IMHO, of course
On Tue, Jun 17, 2014 at 7:29 PM, Alan Shore <ashore@xxxxxxxx> wrote:
I was hoping to use a "quick" SQL query and there are a multitude ofnecessarily represent those of the company.
different formats
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf
Of Jon Paris
Sent: Tuesday, June 17, 2014 12:57 PM
To: Midrange Systems Technical Discussion
Subject: Re: Finding data between XML tags using SQL
Why don't you just use XML-INTO to parse the value in the variable?
On 2014-06-17, at 11:02 AM, Alan Shore <ashore@xxxxxxxx> wrote:
Thanks Carelintended only for the individual named. If you are not the named
Forgot about that SQL command
Let me ponder this for a while
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On
Behalf Of Carel Teijgeler
Sent: Tuesday, June 17, 2014 10:57 AM
To: Midrange Systems Technical Discussion
Subject: Re: Finding data between XML tags using SQL
You could try the LOCATE function in the WHERE-clause
Regards,
Carel Teijgeler
On 17-6-2014 15:18, Alan Shore wrote:
Hi everyone
Before I forget - we are on V5r4
For order settlements, we use a web service with XML Each
transmission (XML request and XML receipt) is stored in a file
My question is (hopefully it makes sense) Using SQL - how can I
display (via SQL) the data between XML tags (including the tags)
For example - if I supplied the XML tags of for the XML RESPONSE
<range> and </range>
I would want the following displayed
<range>0</range>
Etc.
For all the records
Hope this makes sense
I am having trouble trying to think where to start
As always - all answers gratefully appreciated
Anyone
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill
Disclaimer: This message contains confidential information and is
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the
contents of this message, which arise as a result of e-mail
transmission. If verification is required please request a hard-copy
version. Any views or opinions presented are solely those of the
author and do not
http://archive.midrange.com/midrange-l.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
--
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.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
--
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
--
--
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.
Disclaimer: This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. E-mail
transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a result of
e-mail transmission. If verification is required please request a
hard-copy version. Any views or opinions presented are solely those of
the author and do not necessarily represent those of the company.
--
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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
