O$: Null Fields

Christine Penner christine at ingenioussoftware.com
Tue Apr 21 12:53:26 EDT 2009

There is a couple of rows of data we hold in task 
variables. Because they almost never change we 
clear nulls out of them when they are loaded. 
Everywhere else we are going to leave the nulls 
because we don't want to take the extra time to 
walk through anything to clear them (even if the 
time is small). When are finding over 1000 
records the time difference will be noticeable.

This is what I would do with my example. A lot of 
code to check for changes in 2 fields. Anyone 
have a better way knowing there could be nulls in the data?

;call my method
else if 
;call my method
end if


At 09:42 AM 21/04/2009, you wrote:

>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
> >answers.
> >
> >Greetings
> >
> >Peter
> >
> >
> >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.
> >>
> >>Christine
> >>
> >>_____________________________________________________________
> >>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
>Manage your list subscriptions at http://lists.omnis-dev.com

More information about the omnisdev-en mailing list