Here is an example of an SSL Statement that has worked fine until now:
DOS>{04/08/96}&(DOS< {01/01/00}|PROC<>"")&(D<DOS)
D & DOS are date fields. I found previously that any date value > 01/01/00 was interpreted as a blank field, and I have been using this in SSL statements. Similarly, any date < 01/01/00 is interpreted as a non-blank field. Any blank field is interpreted by the language as being greater in value than any actual date. Now that we're in the twenty- first century, these date comparisons don't work. I can't make any date comparisons and my subsets don't work like they used to. All I want to do is find all the records that have blank date fields.
Richard Kline klinerm@home.com
In a similar vein, Steven Karp (skarp@RICOCHET.NET) asks "How do I set up the subset definition to show only those items for which the date field called "Recd" is blank?
Editor's Reply: My guess is that Richard Kline has found another undocumented way to look for empty date fields (i.e. DOS<(01/01/00)). The reason it no longer works is that there's no way for the computer to tell that you mean 01/01/2000 rather than 01/01/1900. My approach is to use another undocumented feature to find empty date fields. What follows is from an article in PTP (May/Jun,1999).
" To find items with empty date fields use the SSL code !*Date Field. For empty number fields use the code !*Number field (i.e., NOT wildcard field name). Note you can also use NumberField0 but this will give you fields that contain a 0 as well as empty fields. For empty time fields use TimeField":"
The use of the wildcard operator with a field name is not supposed to work, but it does, at least for the date and number types of fields. The same trick fails to work for time fields, so look for time fields that do not contain a colon, as in 12:34am. If you're using a time format such as HH,MM,SS you'll have to substitute a comma in place of the colon."