Re: DDS Time vs. DDL Time

On 20-Oct-2011 10:21 , Mike Wills wrote:

I am working through an issue here. I have a C#.NET application that
is uploading data to the i. In one application, I have the file
defined as DDS (old habits don't die) with a time field. In this new
application, I am using DDL to create the file and it also has a
time field. I have basically copied and pasted the line from the
working application to the new application and still doesn't work.
The only difference I can see is DDS vs. DDL. Is anyone able to
confirm there is some sort of difference (even though I don't know
why there would be)?

Working line:
cmd.Parameters.Add("@SUPERVISOR_SIGNED_TIME",
iDB2DbType.iDB2Time).Value =
leaveRequest.SupervisorSignedDateTime.ToString("HH.mm.ss");

Non-working line:
cmd.Parameters.Add("@PAYMENTTIME", iDB2DbType.iDB2Time).Value =
transactions.Transaction.TransactionTimestamp.ToString("HH.mm.ss");

Both leaveRequest.SupervisorSignedDateTime and
transactions.Transaction.TransactionTimestamp are of the same C# type
(DateTime).

The error is:
IBM.Data.DB2.iSeries.iDB2ConversionException was unhandled
Message=A conversion error occurred.
Source=IBM.Data.DB2.iSeries
MessageCode=111
MessageDetails=Parameter: 13.

I am first posting to MIDRANGE-L to eliminate the table out of the
issue.

The DDL supports a concept of "without default" whereas DDS does not, and DDS supports a specific TIMFMT() and TIMSEP() whereas DDL does not. However neither of those should be relevant to the above as far as I can infer; the *ISO time format [hh.mm.ss] being used should be compatible irrespective of any TIMFMT given the activity is SQL versus RLA, and given that an actual value is specified for the I\O there should be no issue for a NULL value being restricted.

Might be worth trying the failing case with a newly created DDS file from the same source, and use that new file versus the old file. If the test is functional, there may be some specific issue with that old file which optionally can be investigated; the old file moved to another library for later review.

Regards, Chuck