We have a field on our database that is defined as varchar 2000. In our master, it is defined as TX50 and TX.

When we execute the following code the draft1 field is always 0 even if the condition should cause it to be 1. We are NOT displaying or using the varchar 2000 byte field so it took me a bit to figure out the issue. What is happening is when we display the entire file, one record is appearing as 5 rows in the output because of the varchar field (there is about 200 characters in the varchar field and since we have it defined as TX50, it goes to 5 lines). I believe my define is looking at the last "line" of my 1st record and seeing blanks for both fields and setting my define to 0. If I change the varchar field to be A200 in my master, the entire record appears on only 1 line and the define works.

What is the best way to define a varchar in the master?
Is there some other setting I should by entering so that my define will work when the field is defined as TX50?
I thought TX50 was how it should be done so that wrapping, etc could be done with the field.

I also tried doing the calc as a compute instead of a define and I got the same result if I left the field as TX50.

Thanks.

DEFINE FILE FOLLOW_UP_INFO
DRAFT1/I2=IF (FOLLOW_UP_RESPONSE NE ' ' AND FOLLOW_UP_COMPL_DT IS MISSING) THEN 1 ELSE 0;
END

TABLE FILE FOLLOW_UP_INFO
PRINT ACCOUNT_NUM FOLLOW_UP_RESPONSE FOLLOW_UP_COMPL_DT
DRAFT1
WHERE ACCOUNT_NUM EQ '123456'
END

As a quick workaround define wf fields with different formats based on the same alias in the database.

eg

FIELD=FOLLOW_UP_RESPONSE_V,ALIAS=FUR,A2000V,A2000V,$
FIELD=FOLLOW_UP_RESPONSE_TX,ALIAS=FUR,TX50,TX,$

Use one for the define test and one to print. I use this technique all the time without problems.

that's a usefull tip H..

This is also a good technique for datetime fields. For example, consider the following:

FILE=kdsassgn, SUFFIX=SQLORA,
SEGNAME=TASSIGNM, SEGTYPE=S0,$
FIELD=AS_ASGNID , ASGN_ID , I8 , I4 ,$
FIELD=AS_BEGDT , STRT_DT , YYMD , DATE ,$
FIELD=AS_BEGDTTM , STRT_DT , HYYMDS, HYYMDS ,$
FIELD=AS_ENDDT , END_DT , YYMD , DATE , MISSING=ON,$
FIELD=AS_ENDDTTM , END_DT , HYYMDS, HYYMDS, MISSING=ON,$
FIELD=AS_STAFF_NM , D_STF_PERS_NME , A80 , A80 , MISSING=ON,$

The STRT_DT is a system date, so they are pretty much guaranteed to be unique when considering time down to the millisecond. To find the most recent assignment for a each Staff person,

TABLE FILE KDSASSGN
PRINT AS_ASGNID AS_BEGDT AS_ENDDT
BY AS_STAFF_NM
BY HIGHEST 1 AS_BEGDTTM NOPRINT
END

The TX format is the old why of handling long character fields from RDBMS's. The A format was increased some releases ago to handle long character formats. The TX field format has some limitations besides the behavior of breaking a field value into multiple records. I have found that using the Annnn format is best. I have not done any testing to see if there is a significant advantage to including the V on the end of the format or not (AnnnnV).

In general, I would recommend using the Annn[V] format instead of the TX. In addition, you can set you WebFOCUS server to create Annnn[V] format fields instead of TX format fields when creating synonyms (MFDs).