[Babase] biograph update_statdate and dcause questions

kfenn kfenn at princeton.edu
Thu Jan 3 10:41:48 EST 2008


Karl O. Pinc wrote:
> 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.
>
I'm checking everything right now to make sure what I THINK I'm doing is 
actually showing up in Babase.  I trust your testing, I just don't trust 
me to always interface with your system correctly.  I thought that if I 
could leave the statdate blank for new individuals, then having it 
populated after the census uploads would confirm for me that I set 
things up correctly for the update to occur....and that I actually 
loaded census info for that individual so that the statdate was 
updated.  I guess putting a birthdate into the statdate field just to 
get it uploaded  is OK, but the birthdate really isn't the statdate (we 
rarely see an individual on the day they are born) and I wouldn't ever 
want it to get left in there accidentally.  I'm more inclined to input 
some really fake date to get around the "cannot be null" issue....like 
2050-01-01, something allowable, but so out of  whack that it would 
catch anyone's attention and I could query by it to make sure it was 
removed.  Is that a bad idea?
>>
>> 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.
>
OK.  I thought that might be the case.  We will enter 0's in this field 
as standard protocol for any alive individual....until such time that we 
can discuss a possible change.  This is low priority considering things 
basically work.

>
>   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.
>
Ah-ha.  We've run into this recently with the undergrads trying to sort 
out data codes and not really knowing where to look.  Can't remember the 
exact issue, but I was confused by why certain things appeared in the 
tech reference and others only appeared in the support tables.  It 
hasn't been consistent, as you say.  Another issue worth revisiting when 
we want to open that can of worms.


Tabby

-- 
Tabby Fenn
Research Assistant

Dept of Ecology and Evolutionary Biology
401 Guyot Hall
Princeton University
Princeton, NJ  08544

609 258-6898 (Ph)
609 258-2712 (Fx)



More information about the Babase mailing list