>> I thought I understood it that any operation involving a NULL value
>> has an unknown result and that a check constraint only watches for
>> a FALSE result so a NULL should be allowed here shouldn't it?

> Not correct. NULL is not a value, it is a state. Your check constraint
> CONSTRAINS any data in that column to be a value, i.e. non-null. It
> further constrains the value of the data to be within your two bounds.

Thanks for answering, but I guess I'm still a bit confused. I'm looking
at a book called "SQL for Smarties" by Joe Celko and he states in it:

"... or to verify that a column's value is in an
enumerated set, such as CHECK (sex IN ('M','F')), with
this constraint. Remember that the sex column could also
be set to NULL unless a NOT NULL constraint is also added
to the column's declaration."

Is that statement incorrect, or is there a difference between how the IN
operator works and how the '"TAX" >= 0 AND "TAX" <= 0.1' formula I used
works? Would 'TAX between 0.00 and 0.10' and 'TAX>=0 AND TAX<=0.1' be
equivalent or are there subtle differences?

> btw, before you go much further, can I suggest some things?

Absolutely! :)

> 1) Avoid using quoted identifiers for db objects except in places where
> you actually need to.

The Interbase DataPump tool actually did that for me automatically (at
least the way I had it set -- I'm still trying to get a handle on the
what all the settings really mean). One of the problems I'm having
moving the data from Paradox is that there are lots of column name
issues (columns named "Date", "Time", "Group", and names with spaces in
them). I can easily strip the quotes off except in the case of invalid
column names -- is that a good thing to do? Any particular reason why?

> 2) Don't use the FLOAT type for things that are going to be used in
> calculations (such as a tax rate). You'll lose control of the precision in
> multiplication and division operations. Use a scaled type, NUMERIC(2,2)
> here, I think, since your constraint allows numbers which are smaller than
> 0.10.
>
> Be careful about floating-point numbers (FLOAT and DOUBLE PRECISION). The
> maxim is to use them only for "things you measure"; and even think those
> cases through if they are ever going to be multiplied or divided.

Again, that decision was made automatically for me and I'm just starting
to try and decide what changes I need to make to the auto-generated
results. I understand the issues with floating point types and will
likely change them once I read up on what data types I have to work
with. I've got lots of reading lined up at the moment. :)

> 3) If those CHAR(1) columns are Booleans (= Paradox type Logical), why not
> define a Boolean domain? (But don't name it BOOLEAN, because true booleans
> are coming in Fb 2...)

For some reason (long forgotten) the fields in Paradox were defined as
A1 rather than as a Logical type. Tthe database was originally designed
a very long time ago in Paradox for DOS, perhaps there wasn't a Logical
field at that time. Anyway, once I get things running again I'm going to
take a long look at fixing a number of odd issues in the data.

The Interbase Datapump actually created a domain statement for me -- I
just don't know how it works yet.

Thank you _very_ much for you help. It's really appreciated!