[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