Re: Which of the SYSIBM tables/views show the row count for

FWIW...first thing i try to get rid of is DFU in any shop. (and DBU,etc.
*dons flame-resistant apparel*) any info i need about a file and it's
attributes and data can be retrieved in less *dangerous* ways.
unfortunately some people *still* insist on using DFU, etc in production
environments (if you want to use 'em do it on a dev/test box. production
machines IMO should never have these tools installed. even if you only
have one machine there are methods available that don't allow you to
tamper with production data directly bypassing the applications.

Thanks,
Tommy Holden



From:
rob@xxxxxxxxx
To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date:
03/10/2008 10:20 AM
Subject:
Re: Which of the SYSIBM tables/views show the row count for



Tommy,

I feel the final checking, the last gate to pass, should be the
constraints. If I can put stuff in there using UPDDTA that I couldn't by
using the application, then something is wrong.

Now, error checking in your applications is a matter of style. Yes, you
could check the status on writes or updates, and perhaps evaluate that
further (maybe even down into the joblog) and evaluate the errors thrown
by the constraints and triggers. And that would be 100% effective (or at
least better be). And, you should probably have this logic in there
anyway in case a new constraint is added. I'll agree with you, it's a
PITA.
I can understand if you want to duplicate this checking in your
application. Makes it easier to highlight fields in error, etc.

Rob Berendt