|  | 
    Nik,
    That is a confusing comment.  I would probably take it to mean that
    only when a foreign key value is updated or inserted would R.I.
    checking be invoked.  Updating or deleting a primary key would not
    invoke any checking.  If this is what IBM means, it's not too
    impressive. 
    
    "Supporting" referential integrity is a little vague, too.  Rdb
    constraints SUPPORT R.I. in that they detect the violation condition.
    They don't totally implement R.I. in that they don't take specified
    actions (e.g., NULLIFIES, CASCADES).  They take only the action
    "RESTRICTS." 
    
    A DBMS couldn't totally implement R.I. without understanding primary
    and foreign keys of the USER relations.  (DB2 has understood these keys
    for SYSTEM tables from 1.0).  It sounds like DB2 will have to at
    least understand these keys now.
    
    I don't know, that's just my shot at it.  I usually have trouble
    understanding what IBM really means anyway.
    
    Paul Krug
 | 
|  |     Initially, IBM announced full referential integrity, including
    primary/foreign key support as well as cascading delete and null
    support. However, two or three months after initial announcement,
    industry consultants began reporting that cascading deletes will
    no be supported initially. I have not yet heard what the technical
    problem was that is holding it up.
    
    I don know that the target date for DB2 Version 2 was set 3 or 4
    years ago based primarily upon the time it would take to do referential
    integrity. The performance and other features were the 'other' things
    that were also possible during the same time. Even if the initial
    release does not support full RI, it is just around the corner.
    In comparison, Rdb can detect RI violations, but cannot yet do the
    cascading either.
    
    Jamey
 |