>How do I set up a table with 2 parents.
>
>I have a contract table:
>
>Contract
>pk_id (I)
>
>
>A child table that lists spaces for the contract (like "office", "warehouse", "retail", etc...)
>
>ContSpace
>pk_id (I)
>fk_space (I)
>fk_contract (I)
>
>A child table that lists tasks for the contract (like "Space plan", "permit drawings", etc...)
>
>ContTask
>pk_id (I)
>fk_task (I)
>fk_contract (I)
>
>Now I need a table to hold the fee minimum for each space/task combination.
>
>ContFee
>pk_id (I)
>fk_task (I)
>fk_space (I)
>fk_contract (I)
>Minimum (N)
>Fee (C)
>
>Is that the correct way to do it? I seems like a PITA to keep the ContFee table matching the 2 parent tables. Everytime a record is added to the ContSpace table, a record for each of the ContTask records need to be added to the ContFee table.

If you performed a SELECT DISTINCT task_name (or whatever) FROM ContTask, how many records would be returned? I'm asking because it sounds like ContTask and ContSpace might return small distinct sets.
I'd drop the fk_Contract field from each of these tables.
Then the ContFee table becomes a many-many-many table relating Contract-Task-Space and adding necessary information about that m-m-m relationship.
You don't say what other info in ContTask and ContSpace relates to that specific Contract-Task and Contract-Space relationship, but if each of these has a fee anyway, it might make sense to move those fields to the ContFee table as well, so then the table could be described as "Attributes for each specific Contract-Task-Space combination"

If you don't want to or can't change the structures of these, I'd suggest dropping fk_Contract from ContFee, since it relates to both ContTask and ContSpace and those in turn relate to Contract. Otherwise, it could get a little squirrely making sure that the Contract key actually belongs with this particular ContTask key and this particular ContSpace key.

HTH (and that I didn't ramble too much)