[Babase] biograph update_statdate and dcause questions

Karl O. Pinc kop at meme.com
Wed Jan 2 15:35:44 EST 2008


On 01/02/2008 12:55:17 PM, kfenn wrote:
> Hi again Karl,
> 
> I finally got a single baboon uploaded into babase_test, biograph.   
> There are two checks in place that are new and are causing me some  
> problems:
> 1)  statdate cannot be null.

> So I have to do the same when using the upload program?  I don't love  
> the idea of having to check every new individual to make sure their  
> statdate gets updated properly after census gets loaded, but I will  
> if this is the only way to get around things.

The system ensures that statdate is the last census date whenever
the individual is alive.  You don't need to check/update new
individuals any more than you need to check/update existing
individuals' statdates.  We tested this thoroughly, but you're
welcome to test some more.

> 
> 2)  Why is the dcause for any status 0 (alive) individual now  
> required to be 0?  Why aren't null dcauses allowed?

Mostly because we never re-designed the dcauses for Babase 2.0.
Foxpro had no NULL value, which is never equal to anything, not
even another NULL.  Foxpro has only 0 and the empty string, which
are completely interchangeable and equal to each other.  So,
because dcause values are numeric, anything that was either
the empty string or zero shows up as 0 in the new system.

I don't know if this was deliberate, or just something we never
went and reconsidered.  I'd guess it was something that came
up in about one sentence and someone right there decided that
it wasn't worth changing.

You're right.  NULL would be a better fit, but I don't know
how it would fit into existing queries etc.  I've no problem
with allowing NULL.

People might have been a little leery of NULL when we first
started moving to Babase 2.0.

   The 0 dcause
> value also isn't explained in the documentation...allowable dcause  
> values are 1-8 in the documentation right now.   Should this be  
> corrected or can we allow null dcauses when status = 0, OR is the 0  
> an artifact of the conversion that you never intended to be an  
> allowable value for the table?

I was against documenting support table values in the technical
documentation, except for values that have intrinsic meaning
to the system itself.  Especially where the documentation is not
in the support table but is in the table where the support table
values are used.  When the documentation was reviewed
Jeanne and Susan added some text to some of the non-support tables
documenting support table data values and I put it without
reviewing against the canonical document -- the actual data in
the support tables themselves.  If we really want to document data
values in this way we will just have to keep the data tables and
the documentation in-sync.

My preference would be to have the support table values be
the canonical reference for what's allowed, and have the
procedure manual say when the different values should be
used.  (And have the technical reference describe the
system's capabilities without getting into such specifics.)
But, that might not make for the most usable system so....

Note that in the documentation for the DCAUSES table
itself there is note of the meaning of '0', because it does
have special meaning to the system.

> 
> I'm sure this is just the tip of the iceberg and I'll be bothering  
> you all week.  Sorry!

No worries!

Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                  -- Robert A. Heinlein



More information about the Babase mailing list