RE: Problem with date zone in SQL fetch -- RPG400-L

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.

Subject: RE: Problem with date zone in SQL fetch
From: rob@xxxxxxxxx
Date: Tue, 27 May 2008 09:25:29 -0400
List-archive: <http://archive.midrange.com/rpg400-l>
List-help: <mailto:rpg400-l-request@midrange.com?subject=help>
List-id: RPG programming on the AS400 / iSeries <rpg400-l.midrange.com>
List-post: <mailto:rpg400-l@midrange.com>
List-subscribe: <http://lists.midrange.com/mailman/listinfo/rpg400-l>, <mailto:rpg400-l-request@midrange.com?subject=subscribe>
List-unsubscribe: <http://lists.midrange.com/mailman/listinfo/rpg400-l>, <mailto:rpg400-l-request@midrange.com?subject=unsubscribe>

That was interesting news to me. Using the CPYF technique, as outlined in
http://www-03.ibm.com/servers/eserver/iseries/db2/pdf/Performance_DDS_SQL.pdf
normally has no problem putting bad data into a DDS defined file from a
"flat" file. However, as you pointed out, a date field in a DDS defined
file still stops the bad data. Apparently there is some checking upon
writes. I wonder if that is because IBM started out fresh with date
fields and could do them right. However, if they started enforcing no bad
data into numerics (on a DDS defined file) thousands of applications out
there would start failing.

Rob Berendt

As an Amazon Associate we earn from qualifying purchases.

Follow-Ups:

RE: Problem with date zone in SQL fetch , Wilt, Charles

This mailing list archive is Copyright 1997-2026 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.