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



Chuck,

I would be the first to agree that "crappy code" should be corrected, and to
be sure that your program does write, at first, the proper data but, and I'm
afraid that sometimes this is a big "but", sometimes one does not have
access to the source program, the ***** provider just didn't know how to
write half-decent software (and maybe that's why they aren't
doing business anymore) and the only way to provide a quick (temporary, I
hope) solution is with a trigger.

Regards,

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



On Mon, Apr 18, 2011 at 10:19 AM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 4/18/11 7:34 AM, rob@xxxxxxxxx wrote:
Redefine the file using SQL instead of using DDS. You cannot get
decimal data errors injected into the file then. <<SNIP>>

Is that not an effective equivalent of "taking a baseball bat to the
person's knees"; i.e. as with contrasting the use of a trigger and use
of a CHECK CONSTRAINT, to correct instead of validate the input? ;-)
http://archive.midrange.com/midrange-l/201104/msg00297.html
He-heh... OK, I purposely omitted\snipped from the quoted text, the
follow-up questions on how the application does or must respond to the
error. :-) And just as alluded in the archived message, the issue will
not be just this one application program, but all programs that might
have similarly "crappy code" for failed assumptions about what specific
error condition transpired; an issue I generally ignore\overlook,
because poorly programmed applications are just that, so I see little
value in adding "so if your applications are poorly written...". :-)

Seriously though, should not the data at the display file be
validated and sanity\bounds-checked versus depending solely on the
database for validity checking? Is all RTF data [or whatever is pasted]
going to be obviously bad decimal data when input to numeric fields, or
might the data be valid decimal yet still be incorrect? And what about
character data fields [beyond decimal fields] for which the database
will not detect and issue any mapping errors? While the validation or
correction of the field data could be pushed down to the database level
[to constraints or triggers], depending solely on the numeric validation
provided by the database level for the SQL TABLE might be a little weak
for the given\subject scenario.?

Regards, Chuck
--
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.