O$: Null Fields

Pedro Santos pedro.santos at macwin.pt
Tue Apr 21 12:42:03 EDT 2009

Hi Christine.

A simple solution is to write a procedure that depending on the type of the column would fill up the list or row with zero or empty values right after you issue the SELECT statement.

The only thing you need to worry after this is before you update or insert the values back into the database you need to have another procedure that checks the values and resets them back to null if (and only if) the column allows nulls.

This is the way we deal with them and it works like a charm.


-----Mensagem original-----
De: omnisdev-en-bounces at lists.omnis-dev.com [mailto:omnisdev-en-bounces at lists.omnis-dev.com] Em nome de Christine Penner
Enviada: terça-feira, 21 de Abril de 2009 17:35
Para: OmnisDev List - English
Assunto: Re: O$: Null Fields

I have looked through the past discussions on nulls. I asked a 
similar question before but they are all more general then what I'm 
looking for. We have decided that we will be dealing with nulls. What 
I want is some suggestions on how to deal with specific things like 
the example I gave. I could write a pile of code checking nulls but I 
thought someone may have a more elegant solution then what I would 
come up with.


At 09:03 AM 21/04/2009, you wrote:
>Hello Christine
>This subject has been discussed many times before and by more
>experienced developers than myself.
>If you do not want to use nulls, don't use them but keep in mind :
>there is a big difference between a value null an an empty value. The
>last has been assigned and the first was not.
>I suggest that you go through the archives to find more specific
>On 21 apr 2009, at 17:23, Christine Penner wrote:
>>Hi Everyone,
>>We are in the process of converting our software to SQL. In the old
>>DML code we never had to deal with nulls much. Now I need some
>>advice how to deal with them in some specific problems that have
>>come up. We decided in most cases we don't want the overhead of
>>always clearing nulls after finding data.
>>When we have one field we are looking at there is no problem. When
>>we have more than one it can cause problems. Here is an example. Any
>>suggestions would be appreciated.
>>If (pOldRow.FF_HIRED<>pNewRow.FF_HIRED)| 
>>In this case we compare old and new values to see if anything has
>>changed. Typically in this situation everything will be null except
>>pNewRow.FF_HIRED. It still fails though because of the nulls. We do
>>this type of thing all over the program. It would be good to not
>>have to write a pile of code each time checking for nulls.
>>Manage your list subscriptions at http://lists.omnis-dev.com
>Manage your list subscriptions at http://lists.omnis-dev.com

Manage your list subscriptions at http://lists.omnis-dev.com

More information about the omnisdev-en mailing list