Don't know if this has already been reported here or not. There is a bug in release 7.7.03 when using the LAST attribute with date comparisons in DEFINEs and COMPUTEs. The following code will cause error (FOC280) COMPARISON BETWEEN COMPUTATIONAL AND ALPHA VALUES IS NOT ALLOWED.

DEFINE FILE GGSALES
 NEWDATE/YYMD = DATE ;
 DATE_BAD/I1  = IF (LAST NEWDATE EQ '') THEN 1 ELSE 0 ;
 DATE_1996/I1 = IF (LAST NEWDATE FROM '19960101' TO '19961231') THEN 1 ELSE 0 ;
END

TABLE FILE GGSALES
 PRINT NEWDATE
       DATE_BAD
       DATE_1996
 WHERE RECORDLIMIT EQ 200 ;
END

Remove both LAST attributes from the above code and it works just fine.

The following code is a work-around for this problem:

DEFINE FILE GGSALES
 NEWDATE/YYMD = DATE ;
 NULL_DATE/YYMD = '';
 BEG_DATE/YYMD  = '19960101';
 END_DATE/YYMD  = '19961231';
 DATE_BAD/I1  = IF (LAST NEWDATE EQ NULL_DATE) THEN 1 ELSE 0 ;
 DATE_1996/I1 = IF (LAST NEWDATE FROM BEG_DATE TO END_DATE) THEN 1 ELSE 0 ;
END

TABLE FILE GGSALES
 PRINT NEWDATE
       DATE_BAD
       DATE_1996
 WHERE RECORDLIMIT EQ 200 ;
END

This message has been edited. Last edited by: Dan Satchell,

Have you confirmed with IBI this is a bug?

No, I haven't opened a case with IBI.

I don't think this is a bug, it is the way it is coded. Remember that internally a smart date is an integer and you are comparing NEWDATE to '', and '' is not an integer. In GGSALES, DATE does not have the MISSING attribute. This means that records will be 0, which is 12/31/1900, or be a regular date. You may be the victim of code tightening on IBI's part.

I have always coded this situation (boolean logic) like this:

DATE_BAD/I1=LAST NEWDATE EQ 0;

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

As far as I can remember, code similar to that in my example has worked since SmartDates were introduced over ten years ago. Null/blank dates aside, code tightening would still not explain why the second date comparison between NEWDATE and the 1996 date literals fails (both with and without the single quotes), nor why both DEFINEs fail when LAST is used but run without error when LAST is removed.

This message has been edited. Last edited by: Dan Satchell,

Let me rephrase, you may be the victim of code tightening on IBI's part that went too far.

I'm on 7.6.11 and the orginal code works fine.

Hi Dan,

If you have not done so, like others have suggested, please contact Customer Support Services and open a case for assistance. The phone number is 1-800-736-6130, or access online at InfoResponse.

Cheers,

Kerry

I'm amazed...

I never use LAST in defines, because it doesn't make sense to do so.

For starters you have no idea what the 'LAST' row is because that's determent by the BY-fields in the TABLE.

How is this suported to work with a SUM verb anyway?

And yes I know. You using PRINT.
But if you are using PRINT anyway why use a DEFINE? Use a COMPUTE instead!

DEFINEs are single database line statements, I'm surprised WF doesn't just give an error when using LAST in a DEFINE.

I opened case #73412​541 with IBI.

quote:

********************** COMMENTS FROM INFORMATION BUILDERS **********************

Hi Dan, this looks like a bug. I will send it to programming.
Regards,
Cesare

********************************************************************************

quote:

I never use LAST in defines, because it doesn't make sense to do so.

Sure it does:

DEFINE FILE CAR
   EVERY_OTHER/I2 = IF COUNTRY NE LAST COUNTRY THEN
                      IMOD(EVERY_OTHER + 1,2,'I2') ELSE EVERY_OTHER;
END
TABLE FILE CAR
PRINT COUNTRY CAR MODEL
 EVERY_OTHER
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
UNITS=IN,
SQUEEZE=ON,
ORIENTATION=PORTRAIT,
$
TYPE=REPORT,
GRID=OFF,
FONT='ARIAL',
SIZE=9,
COLOR='BLACK',
BACKCOLOR='NONE',
STYLE=NORMAL,
$
TYPE=DATA,
BACKCOLOR='NONE',
$
TYPE=DATA,
BACKCOLOR=RGB(190 235 255),
WHEN=EVERY_OTHER EQ 1,
$
ENDSTYLE
END

Of course, the datasource must be pre-sorted for this to work. That can always be accomplished
by doing a print-by to a hold file. . .

Rob

I agree with Rob. I do this all the time especially when the data source is Oracle and Oracle has already sorted the data. Most of the time I can use TABLEF which prevents WebFOCUS from resorting the data. Depending on the size of the return set, this can be much faster.