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


  1.  Home
  2. MIDRANGE-L
  3. June 2014

Re: Finding data between XML tags using SQL

Luis,

Yes, it depends, like always.

The one business need that i related to in my comment was that software
should be easily adaptable to new or changed business needs. One way to do
that is to make things transparant. To not use obscure SQL functionality
and instead use straight (RPG) code. YMMV






On Wed, Jun 18, 2014 at 4:17 PM, Luis Rodriguez <luisro58@xxxxxxxxx> wrote:

John,

I agree that, in many cases, people use SQL where a RPGLE based solution
would be more efficient or practical.

On the other hand, I would argue that this depends on the user (in this
case a developer) needs. I do not know if he wants to use this in a
JDBC/ODBC environment, to be called from another system. Or maybe he needs
it as an input for another SQL statement.

What I am trying to express is that, as I see it, we as developers have
multiple tools available, be either SQL, “pure” RPGLE or even a SQL
procedure (or UDF/UDTF) that calls an RPGLE program. It always depends, I
think, on the user/business needs.

Also, nowadays we have multiple interfaces that access our data (Excel,
browsers, other SQL engines, etc) and need SQL-based solutions. As I see
it, the trend is to have more and more of the business logic “embedded” in
the database and, for this, you need to go the SQL way (even for some
“trivial” things).

My 0.02 cents :-)

Best Regards,

Luis

Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries
--



On Wed, Jun 18, 2014 at 8:47 AM, John E <whattssonn@xxxxxxxxx> wrote:

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 of
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 Carel
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
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.

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


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



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.