Here's a new one, at least for me: I have a field in the source file (1010data) which has a value of "09/03/13_21:30:00" which displays as "09/03/13_21:29:59" in my WebFOCUS report. It's in the synonym as "FIELDNAME=STARTTIME, ALIAS=STARTTIME, USAGE=HYYMDS, ACTUAL=HYYMDS, MISSING=ON, $".

What I want is for it to display as "09/03/13 21:30:00" or "2012/09/03_21:30:00"... Not ...29:59

I appreciate your thoughts on this.

~ Doug

This message has been edited. Last edited by: <Kathryn Henning>,

What do you get if you pull the datetime as an A17 field ?

I get

 ERROR AT OR NEAR LINE     10  IN PROCEDURE ADHOCRQ FOCEXEC *
 (FOC36346)  INCORRECT USE OF DATE-TIME FIELD OR CONSTANT
 (FOC009) INCOMPLETE REQUEST STATEMENT
 BYPASSING TO END OF COMMAND

When I do a

COMPUTE HYYMDa17/A17 = ADJSTARTN ;

OR

COMPUTE HYYMDa17/A17 = EDIT(ADJSTARTN) ;

This message has been edited. Last edited by: Doug,

I get this:

LIST STARTN              HYYMDs                  HYYMDS              HYYMDm 
1    2013/09/03 21:29:59 2013/09/03 21:29:59.000 2013/09/03 21:29:59 2013/09/03 21:29:59.000000 
2    2013/09/03 18:00:00 2013/09/03 18:00:00.000 2013/09/03 18:00:00 2013/09/03 18:00:00.000000 
3    2013/09/03 16:59:59 2013/09/03 16:59:59.000 2013/09/03 16:59:59 2013/09/03 16:59:59.000000 
4    2013/09/03 13:00:00 2013/09/03 13:00:00.000 2013/09/03 13:00:00 2013/09/03 13:00:00.000000 

From this:

TABLE FILE [FILENAME]
LIST STARTN 
COMPUTE HYYMDs/HYYMDs = STARTN ;
COMPUTE HYYMDS/HYYMDS = STARTN ;
COMPUTE HYYMDm/HYYMDm = STARTN ;
. . .
END

I was suggesting changing the field forat in the master.

And it wasn't A17, its A23.

I think it is:
FIELDNAME=STARTTIME, ALIAS=STARTTIME, USAGE=A23, ACTUAL=A23, MISSING=ON, $

This will show you what is being returned from the call to the DB.

Would you see a difference if you change the definition of STARTN in your master to ACTUAL=HYYMDm, USAGE=HYYMDm so the adapter reads the value with the highest precision possible?

Being as it is right now, STARTN is only getting data down to the SECOND, and I guess that any further COMPUTE to try to get more granular information (s, m) may not work as that information is already "lost" in virtue of the source value being read as HYYMDS.

FORMAT  SHOWS AS
A17     .
A23     2013-09-03 21:29:59
HYYMDS  2013-09-03 21:29:59

It may be getting lost in translation. I'm working on vairous options in a copy of the synonym (to the same table) now.

Are you sure the other end isn't rounding ?
Is the source 21:29:59, but is rounding to 21:30:00 in display.

The A23 should show the value retrieved from the DB.

I'm still checking in to that Waz. They say it's 2013/09/03 21:30:00. But, I'm seeing 2013/09/03 21:29:59. I may open a case on this...

can you do math with these dates?
if so, how about add half a second?

Yeah, but the issue is that it doesn't seem consistent, as to when the second is lost. It's lost on some values and not on others. It may be time for a Case

Have you tried another client to access this data and see what that pulls out ?

I have a nasty feeling that this is a byproduct of the way that the datetime is stored in the DB.

We've found inconsistent rounding on numeric columns since we upgraded from v7.7.03 to v.7.7.05 (I haven't paid attention to date/time columns).

I hope not and I have faith in 1010data. I did open a case with IB and we'er working on it. But, this may be a byproduct of the way that the datetime is stored in the DB. I'll keep you posted.
Not sure if I should be or .

quote:

We've found inconsistent rounding on numeric columns since we upgraded from v7.7.03 to v.7.7.05

Can you give more details on this, it worries me a lot.

Formats, etc ?

Sorry for the alarmist comment - this happens when retrieving data from Oracle. Case number 92732542.

This occurs when the column is defined as a NUMBER in Oracle, without scale or precision. WebFOCUS metadata default for these columns: USAGE=D20.2, ACTUAL=D8

"It makes no sense that x.415 becomes 0.42 while x.715 becomes x.71. It's just plain inconsistent."

The rounding seemed to have changed in the data adapter. Unfortunately the database modeller was perhaps lazy when designating the size of the numeric columns.

Thanks Francis, a bit of a load off......

IB found an issue in the 1010data Adapter which we're using and has provided the new adapter to us. Now, to get that in place...