Help with expression in report 2

[Bryan - Gendev]

I have the expression below for a field in my report

<code>

IIF(empty(princ_1),' ' ,transform(mydsid)+' : '+transform(pr1_num))

</code>


If princ_1 is not empty I would see say 1:999999 where dsid = 1 and pr1_num = 999999

However when princ_1 is empty I don't want anything to print.

What I do see is 1: for the dsid.

Can anyone suggest where my error is please?

GenDev

 

[Olaf Doschke]

Well, what is princ_1 in this situation? Should be easy to find out.

Empty() includes spaces and tabs, but not all chr with low n, which are not printable in tems of strings, empty() also is true for empty dates, .F. as logical "empty", but it's also .F. for NULL.


Bye, Olaf.

 

[Olaf Doschke]

to clarify the last bit: Empty(.F.) is .T. , Empty(.NULL.) os .F.

And overall princ_1 can't be empty, if you get "1:", there has to be something in it, there is no such IIF bug, that this would happen when princ_1 is empty.

Bye, Olaf.

 

[Mike Lewis]

Just to follow up Oaf's point:

If you display [tt]TRANSFORM(princ_1)[/tt], either from within your program or from the debugger, you will get a good idea of what princ_1 contains. If it contains NULL, it will appear as [tt].NULL.[/tt]; an "unprintable" character, it will show as a small hollow square; .F. will display as [tt].F.[/tt], and so on.

That should help you recognise values that might not normally be visible, but which don't pass the test for EMPTY().

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

TRANSFORM(.NULL.) will look empty, if SET NULLDISLPAY TO "" is used to suppress NULLs in ouptut, so you won't see that.
I rather recommend looking into the data itself.

One more thought: If you query into some table or cursor before DO REPORT FORM, then rather inspect that than source data. .NULL.s mostly will appear in queries with outer joins, even from non nullable fields.

Bye, Olaf.

 

[Olaf Doschke]

>.NULL.s mostly will appear in queries with outer joins
To clarify: In cases you don't expect NULLs as source data doesn't allow them, they are mostly coming from queries allowing them.

Bye, Olaf.

 

[Mike Lewis]

Some other thoughts:

Is princ_1 a variable or a field?

If it's a field, is it possible that it is present in two different tables (or cursors)? And that it has different values in the different tables? And that the table in the current work area is not the one you thought it was? (In other words, you should prefix the field name with the table alias.)

If it's a variable, are you it is in the correct scope?

Or is it possible that it is both a field and a variable? And it's the variable that contains the value you want to test? (In which case, the report will be seeing the field rather than the variable; so you should prefix the variable name with m.)

Just a few random ideas.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads