|
CRTSQLRPGI defaults to DATFMT(*JOB) and the job format, for me anyway, is *MDY. And, why override CRTSQLRPGI defaults when you can use the SET OPTION stuff? Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com |-----------------------------+-------------------------------------------| | "Carmen Nuland" | | | <cnuland@xxxxxxxxxxxxxx> | | | Sent by: | To| | rpg400-l-bounces@midrange.| <rp| | com | g40| | | 0-l| | 08/12/2004 12:39 PM | @mi| | | dra| | Please respond to | nge| | RPG programming on the | .co| | AS400 / iSeries | m> | | <rpg400-l@xxxxxxxxxxxx>| cc| | | | | | Fax to| | | | | | Subject| | | RE:| | | SQL| | | Dat| | | e | | | pro| | | ble| | | m | | | | | | | | | | | | | | | | | | | |-----------------------------+-------------------------------------------| The value of Scn_Date in the dump was *Loval: SCN_DATE DATE(10) '0001-01-01' It looks like it's actually failing on the "Open" statement. I verified all the dates in the file were correct. As shown by Matt Tyler in a previous post, adding SET OPTION DATFMT = *ISO before the other statements seemed to take care of the problem. It would be nice to know why, so I could avoid this in the future... Carmen -----Original Message----- date: Thu, 12 Aug 2004 11:42:04 -0500 from: rob@xxxxxxxxx subject: Re: SQL date problem The problem is that Scn_date is formatted wrong. Like it was left blanks, etc. When you get that error, what is the value of scn_date? Because you are not selecting any date fields: line#, control, text, then I wouldn't think it was a null value issue. I am not so sure that it's even dying in the SQL. Run it in debug and tell us exactly where it dies. Granted, imbedded sql makes your debugging a little squirelly. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com |-----------------------------+-------------------------------------------| | "Carmen Nuland" | | | <cnuland@xxxxxxxxxxxxxx> | | | Sent by: | To| | rpg400-l-bounces@midrange.| <rp| | com | g40| | | 0-l| | 08/12/2004 11:23 AM | @mi| | | dra| | Please respond to | nge| | RPG programming on the | .co| | AS400 / iSeries | m> | | <rpg400-l@xxxxxxxxxxxx>| cc| | | | | | Fax to| | | | | | Subject| | | SQL| | | dat| | | e | | | pro| | | ble| | | m | | | | | | | | | | | | | | | | | | | |-----------------------------+-------------------------------------------| I am relatively new to the SQLRPGLE arena, and am having a problem with a date field. In this SQL statement: C/EXEC SQL C+ Declare C1 cursor for C+ select Line#, Control, Text from DETAIL C+ where Custno = :Scn_Custno C+ and SentDate = :Scn_Date C/END-EXEC My problem is that in a particular example, it isn't going to find any records in DETAIL. When I run this SQL statement interactively, it just returns a blank screen. When I run it in RPG, I get the following message (RNX0114): Message . . . . : The year portion of a Date or Timestamp value is not in the correct range. Cause . . . . . : A conversion was requested to a Date value, from a Timestamp or a Date value, and the year of the source Timestamp or Date is not in the allowable range of the target. -- The range for a 2-digit year is 1940-2039. -- The range for a 3-digit year is 1900-2899. -- The range for a 4-digit year is 0001-9999. I'm assuming this has something to do with returning null values, but I'm not sure how to fix it. Carmen -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
