Hi all,
I need to hide cell based on certain condition that cell is NULL. we can do this for records at Table level. But I need to do this for a specific cell.
Thanks,
NewtonsApple (BOB member since 2009-08-11)
=If([Your_Object]=" ";0;[Your_Object])I hope this will do.
Cheers,
[Moderator Edit: Added code formatting - Jansi]
When posting code samples please use the code option for formatting. It will preserve any indenting or formatting that you may have done.
shiva.tomar (BOB member since 2007-10-05)
=If(Not(IsNull([Your_Object]));[Your_Object])You can ignore the else part.
Jansi 
(BOB member since 2008-05-12)
=If(Not(IsNull([Your_Object]));[Your_Object])As the object is at report level: This is not so promising in terms of performance as this uses multiple functions inside it and each function is dependent on the other. (Just another input)
There its better to use:
=If([Your_Object]=" ";0;[Your_Object])This simple and shorted your definition of the Object is, the better you can design your variables. (Not always true but a best practice).
Cheers,
shiva.tomar (BOB member since 2007-10-05)
I don’t think there is a performance issue. If that is what we go for, we again have to apply an alerter to hide that 0 right? :?
Jansi (BOB member since 2008-05-12)
Dear Jansi,
No Offenses, but its just another input from my side … 'coz we dont need to supress that 0 as most of the numeric column gets used in some calculations in a real time scenario. And 0 is the best replacement for the business users as they understand that their value is unchanged due to no inputs on that particular day or with that particular transaction. Whereas a blank still keeps them inquisitive.
I’ve written what i’ve always experienced.
And believe me for our previous clients we used (“IF”, “Not” and other functions instead of “Case” - for defining variables… believe me the technical consultant from client’s side rejected the reports at the time of UAT. 
Their consultant said it very clearly … we have huge transactions and we dont want un-necessary complexities in the report.) So we had to re-design the reports… It does give a performance issue. (Kindly check). (I was new to BO then.)
Anyways. Once again No-offenses…
In fact, You’ve provided a different approach to many people here. 
I hope we share the same logic.
shiva.tomar (BOB member since 2007-10-05)
[quote:9755607ef6=“shiva.tomar”]
=If(Not(IsNull([Your_Object]));[Your_Object])As the object is at report level: This is not so promising in terms of performance as this uses multiple functions inside it and each function is dependent on the other. (Just another input)
There its better to use:
=If([Your_Object]=" ";0;[Your_Object])This simple and shorted your definition of the Object is, the better you can design your variables. (Not always true but a best practice).
[/quote]
But, this would be wrong. " " is not the same as NULL. Further, you can’t compare a numeric field to " ".
As for performance, the difference would be very insignificant.
I agree that this is the wrong place to eliminate the transactions. Those should be eliminated during the query. But, if they are not, then the original solution is fine and works for all types of fields.
Steve Krandel 
(BOB member since 2002-06-25)
[quote:8aa7f5a407=“shiva.tomar”]
=If(Not(IsNull([Your_Object]));[Your_Object])As the object is at report level: This is not so promising in terms of performance as this uses multiple functions inside it and each function is dependent on the other. (Just another input)
There its better to use:
=If([Your_Object]=" ";0;[Your_Object])This simple and shorted your definition of the Object is, the better you can design your variables. (Not always true but a best practice).
[/quote]
But, this would be wrong. " " is not the same as NULL. Further, you can’t compare a numeric field to " ".
Steve Krandel (BOB member since 2002-06-25)