>Snip..
>>
>>You brought up a good point about the nulls. I actually have them in my result set, because there were a number of events for which I didn't have any people registered. That's good info, i.e. I want to show total participation for all events, and want to know if there are events for which I have no participants, but I don't really want to have the results show up on a report as null. I don't know if there is some way to account for this at the report level, or I need to limit the use of nulls in my table to fields for which a null is really a valid value (i.e. they may have an address, but I just don't know it or they may not have an ad address), as opposed to a situation where either there are participants or there aren't. Do you have any advice on this?
>>
>>Sylvia
>Sylvia,
>Nulls are especially important where an empty() (including 0) should be differed from "I don't know-I forgot to enter" (ie: in a disease reporting system "0" reporting is important). You should decide the importance for your case. By default set null is off and that means ALTER TABLE, CREATE TABLE and INSERT - SQL wouldn't allow nulls unless you specify a column to allow nulls. New values are automatically inserted as empty() values. Handling null values is sometimes mandatory ie: oldval()=this.value might cause an error on a buffered table where oldval() could be null. Well nvl() is there to help and you could use it in your report too (nvl(oldval("myfield","mytable"),"")==this.value).
>But you use nulls or not these type of joins present null if there is no corresponding value. You could avoid it directly in SQL :

select t1.f1, nvl(t2.f2,"") as f2 ..

but that's a lot of coding. Controlling at report level might be easier.
>Cetin

Thanks Cetin,

I guess I will have to think a little bit more about whether I really want nulls in this case or not. I appreciate your input.

Sylvia