For some reason, I've started get the following error:

quote:

(FOC1426) DATA ELEMENT VALUE TOO BIG FOR SEGMENT/FIELD : yVEWOPRO/COMPL_DT

To be honest, I'm not sure if this message hasn't always been kicked up, but lately the report hasn't been working. But I'm not sure what's wrong here.

The field in the database (compl_dt) is a DATE column type.

Here's the entry from the master file:

quote:

FIELD=COMPL_DT ,compl_dt,
YYMD ,DATE ,MISSING=ON ,$

Any idea what's wrong with that combo?

I would say that this is is a data issue - invalid data row in the database column.

quote:

(FOC1426) DATA ELEMENT VALUE TOO BIG FOR SEGMENT/FIELD %1%2%3%4
An error occurred when converting a data item for the field in the
segment with the names given in the message. Data could not be
converted without truncation from the USAGE to the ACTUAL format.
FOCERROR is posted to 1426.

Now that I look at it a little more, it seems that NONE of the date fields are working. And I reviewed the data in the db, and it looks fine.

I guess I need to figure out what's changed on the server that could cause this.

Where in the report are you using this field

I remember I have seen this message before when I used a field in a heading with something like "

	Frank
	prod: WF 7.6.10 platform Windows, databases: msSQL2000, msSQL2005, RMS, Oracle, Sybase,IE7 test: WF 7.6.10 on the same platform and databases,IE7

Poss the date is an alpha date - use sim to this to read it.

FIELD=EMH_DATE_TUPE_RS_CALCULATEDM, ALIAS=HISTORY_TYPE8, USAGE=DMYY, ACTUAL=A10, MISSING=ON, TITLE='Date,TUPE,RS,Calc', DESCRIPTION='Date TUPE RS Calc', $

Chris, you don't say what data base you are using or what release of WF you're using.

We are using Oracle. Oracle date fields are really date-time stamps. We started getting this error after we upgraded from WebFOCUS 5.3 to WebFOCUS 7.1. With IBI's help and from looking at the traces we concluded that in WF53 DATE was processed as Oracle internal type 12 where in WF710/WF711 as DATE was an internal type 187 (that is more as TIMESTAMP(0) rather then DATE). This was fixed by project which is in WF712.

The real problem was that earlier releases or Oracle somehow allowed an invalid time to be writted as part of the date/time field the database and when WF 7.1 tried to retrieve the row, Oracle object.

Here's some code to help find bad dates. In this case, some exit transaction dates had bad time stamps. I had to fix several tables before we found what we needed to do to fix the problem, which was to upgrade to WF 7.1.3.

SET SQLENGINE=SQLORA
SQL SET SERVER &&KIDS_SERVER
-*
SQL PREPARE PLCMENTS FOR
SELECT CL_ID,
SEQ_NBR,
RSRC_ID,
LST_UPDT_DT,
EXIT_DT,
EXIT_RESN_TYP_CDE,
SUBSTR(TO_CHAR(EXIT_TRANSACTN_DT,'YYYYMMDD HH24:MI:SS'),1,17) TRNSDT1,
TO_CHAR(EXIT_TRANSACTN_DT,'YYYYMMDD') TRNSDT2
FROM TCHLD_PLACEMENT
WHERE EXIT_DT IS NOT NULL
AND TO_CHAR(EXIT_TRANSACTN_DT,'YYYYMMDD HH24:MI:SS') = '00000000 00:00:00'
ORDER BY CL_ID, SEQ_NBR
END
-*
DEFINE FILE PLCMENTS
PL_CLID/I8=CL_ID;
PL_SEQ/I5=SEQ_NBR;
END
-*
TABLEF FILE PLCMENTS
PRINT PL_CLID PL_SEQ RSRC_ID TRNSDT1/A17 TRNSDT2/A8 LST_UPDT_DT EXIT_DT EXIT_RESN_TYP_CDE
END

If anyone is interested, here's how Oracle stores date fields:

Per http://metalink.oracle.com
Note:69028.1 "How does Oracle store the DATE datatype internally?":
DATE is specialized 7-bytes datatype - not an integer:
BYTE Meaning
---- -------
1 Century -- stored in excess-100 notation
2 Year -- " "
3 Month -- stored in 0 base notation
4 Day -- " "
5 Hour -- stored in excess-1 notation
6 Minute -- " "
7 Second -- " "