Help try to duplicate error with UTime on iSeries ...

[craig_welton]

Hello all,

I'm seeing a bizarre issue on the fat client with iSeries/DB2 and was hoping someone with the same setup could give it a go. (I'm working with Oracle, but you know how slow that is)

It's only happening with the data on the iSeries and we are on 9.0, TR 8.98.4.2.

OK, update a PO header (F4301) and set the UTime column like it is below ... (obviously refer to a valid PO in your system; the time is the important bit)

update dv900dta.f4301 set phpohu01 = '2011-12-21 20:20:32.400000' where phdoco = 555574 and phdcto = 'OF'

Now try and fetch the record using UTB. I receive a buffer overrun dialog and the process crashes. Same thing happens if running a BSFN locally that fetches the record using JDB_Fetch API. JAS access does not have any problems.

Now, update the time to be '2011-03-05 12:50:32.000000' (no miliseconds) and we won't get the overrun but do get INVALID UTIME in the UTB grid column.

It appears that any UTime with seconds = 32 and hour > 0 is not getting translated properly.

Hoping someone can give it a quick test ...

thanks a lot,
Craig

 

[MagarG]

Got the same results on our system. I'm not familiar with the JDE Utime datatype.

 

[craig_welton]

Thanks, I appreciate you taking the time. At least I now know it's not just a localalized issue and hopefully Oracle will address it.

From what I understand, the UTime is a Universal Time column that can store a date/timestamp. The value in the database is stored at GMT and is adjusted display wise based on the user's current timezone. So If I write a record at high noon the timestamp will be 17:00 (12:00 + five hours for my timestamp offset of EST). It's appearing in more and more tables, so this issue could rear it's head going forward.

thanks,
Craig

 

[Daniel Prado]

[ QUOTE ]
Thanks, I appreciate you taking the time. At least I now know it's not just a localalized issue and hopefully Oracle will address it.

From what I understand, the UTime is a Universal Time column that can store a date/timestamp. The value in the database is stored at GMT and is adjusted display wise based on the user's current timezone. So If I write a record at high noon the timestamp will be 17:00 (12:00 + five hours for my timestamp offset of EST). It's appearing in more and more tables, so this issue could rear it's head going forward.

thanks,
Craig

[/ QUOTE ]

Hello,
I'm sorry by get up the thread, but can you explain a little better how the Utime (POHU1, POHU2) item works?

Thanks,
Daniel.