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



So what happens if you have not adopted and or converted to the DDL way of
coding. Everything I am today is still DDS oriented.

On Wed, Nov 7, 2012 at 7:35 AM, Luis Rodriguez <luisro58@xxxxxxxxx> wrote:

BTW, I forgot to mention that under 7.1 (and 6.1, thru a PTF), there is a H
spec: VALIDATE(*NODATETIME) , that allows you to "bypass" RPG's normal
checking for date/time values done at read time so (in theory, at least),
operations performed to this type of fields should be faster.

Of course, you should be sure that your date/time fields are always valid.

Regards,
Luis

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




On Wed, Nov 7, 2012 at 7:54 AM, Luis Rodriguez <luisro58@xxxxxxxxx> wrote:

Jack,

If you define your tables using DDL statements, every operation you do
using embedded sql returns a SQLCODE. This code determines either the
success or the appropriate error message for the statement you are
executing. Also, you can't write invalid data on a DDL-defined table
(there is no MCH1202!!).

SQL tables are checked at write time, opposed to DDS tables that are
checked only at read time. So, if you have a table with a lot of reads
but
few writes/updates, SQL should be faster processing it.

On the other hand, things like RUNSQLSTM "abort" with (mostly) a SQL9010
message and is up to the developer (again) to check any particular error
.

HTH,


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





On Wed, Nov 7, 2012 at 6:07 AM, Jack Kingsley <iseriesflorida@xxxxxxxxx
wrote:

I was going to post a question similar to this but thought i would just
ask
it based on this one. Someone posted another question the other day
about
setll and sql and changing program code. Here is my question. If your
doing updates and or inserts using embedded sql, runsql, scripts or the
like what protects the data for "bad data".

On Tue, Nov 6, 2012 at 2:51 PM, Dean Eshleman <
Dean.Eshleman@xxxxxxxxxxxx
wrote:

Thanks Alan. I'll give it a try.

Dean Eshleman
Software Development Architect

Everence Financial
1110 North Main Street
PO Box 483
Goshen, IN 46527
Phone: (574) 533-9515 x3528
www.everence.com<http://www.everence.com>

On 11/6/2012 12:02 PM, Alan Shore wrote:
This is off the top of my head
With groupedfile as
(select distinct a.key1, a.key2, a.key3, a.Cmpsn_Type from fileA as
a),
Countedfile as
(select b.key1, b.key2, b.key3, count(*) from groupedfile as b
Having count(*) greater than 1)
Select c.key1. c.key2, c.key3, d. Cmpsn_Type from countedfile as c
join
fileA as d on
c.key1 = d.key1 and
c.key2 = d.key2 and
c.key3 = d.key3

or something to that effect

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dean Eshleman
Sent: Tuesday, November 06, 2012 11:54 AM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: Validating data with SQL

I have 2 files. A detail file and a summary file. There is a field
in
both files called Compensation type. The summary file is based on
rolling
up the data from the detail file based on 15 key fields. All of which
are
attributes in the detail file. I am trying to verify that all of the
detail records for a given set of keys have the same Compensation
type.
If
they don't, having the Compensation type at the summary file level
doesn't
make sense.

Here is some sample data: (I shortened the # of key fields to make
it
easier to understand)
Key1 Key2 Key3 .... Cmpsn Type
1 2 3 Gold
1 2 3 Gold
1 2 3 Gold
1 2 3 Gold
1 3 5 Silver
1 3 5 Silver
1 3 5 Bronze
2 1 1 Bronze
2 1 1 Bronze
2 1 1 Bronze
2 1 1 Bronze
2 1 1 Bronze
3 2 1 Gold

In this set of records, I'm trying to identify the situation for the
second set of keys (1,3,5) where the Compensation type is Silver on 2
records and Bronze on the third.

Dean Eshleman
Software Development Architect

Everence Financial
1110 North Main Street
PO Box 483
Goshen, IN 46527
Phone: (574) 533-9515 x3528
www.everence.com<http://www.everence.com>






________________________________________
Confidentiality Notice: This information is intended only for the
individual or entity named. If you are not the intended recipient, do
not
use or disclose this information. If you received this e-mail in
error,
please delete or otherwise destroy it and contact us at (800)
348-7468so
we can take steps to avoid such transmission errors in the future.
Thank
you.
_______________

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





________________________________________
Confidentiality Notice: This information is intended only for the
individual or entity named. If you are not the intended recipient, do
not
use or disclose this information. If you received this e-mail in
error,
please delete or otherwise destroy it and contact us at (800)
348-7468so
we can take steps to avoid such transmission errors in the future.
Thank
you.
_______________

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

Follow-Ups:
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.