Conference orarep::nomahs::dec_data_distributor

    
    Marta,
    
    When the DDAL product was first implemented years ago, Rdb would not
    allow any changes to the definition of source tables which were marked
    to be replicated.  In recent years there was a slight change to this. 
    One or two attributes are allowed to be changed, but I don't recall
    which ones.  Default value might have been one of them.
    
    Assuming for the moment that Rdb will allow the default value to
    change, be aware that that attribute is not then changed in the target
    table definition.  You have to do that yourself.
    
    Now, there are two default value attributes.  One is applied by Rdb to
    a column value as a row is being stored in the source database if the
    column value passed to Rdb is null.  If that is the one you're talking
    about, the change would only affect new rows inserted into the source
    table.  The other type of default value is applied when a row is read
    from the source database.  If at that time a column value is null, the
    default value is passed instead.  In such case, the default value is
    passed to old and new rows alike.  However, if you are talking about an
    existing replication transfer (I assume you are), the affected columns
    would not appear as changed columns to be replicated.  You'ld have to
    start the transfer over from the beginning (STOP, REINITIALIZE, START).
    
    It's difficult to explain in a few words.  I hope this makes sense.
    
    Claude

~    Now, there are two default value attributes.  One is applied by Rdb to
~    a column value as a row is being stored in the source database if the
~    column value passed to Rdb is null.

This is not true.  The SQL DEFAULT is only used if the column is not
referenced in an INSERT statement.  If the column value is null then NULL is
stored.

~If that is the one you're talking about, the change would only affect new
~rows inserted into the source table.

~The other type of default value is applied when a row is read from the source
~database.  If at that time a column value is null, the default value is passed
~instead.  In such case, the default value is passed to old and new rows alike. 

The other form of default is the DEFAULT FOR DATATRIEVE and is only used by
the DTR product, not by Rdb at all.  Not for READ and not for WRITE...

If you were referring to MISSING_VALUE then that value is used to set the NULL
bit on insert, and it is returned if the row is null.

I do not believe you'll be able to ALTER the table to change the DEFAULT.

Ian

    
    I stand corrected.
    
    Claude

  Hi Claude,


     Thank you very much for your answer.

     Yes, you're right, we are talking about an existing Replication transfer
     and we want to define a default value for some columns with a NULL value.
     So, if we make these changes to the source table, these changes are
     going to affect to the new rows that are going to be inserted, so only
     these new rows are going to be copied to the target database by the 
     transfer, the existing rows are going to stay unchanged. We have to apply
     the same changes to the target database, or stop and recreate the transfer
     from the beginning, are we right ? 


     Awaiting for your comments.

     Best regards and  Happy Christmast

	Marta.
    

  Claude and Ian,


     I'm sorry for my last reply (*.4), I've written it without haven't read
  Ian's reply. After having read all them, we've realized that we must use 
  another workaround.

  Thank you very much indeed and best regards,


     Marta

When a transfer is defined on a table you can not perform the following:

    add a column
    drop a column
    alter the data type of an existing column
    add or drop a DEFAULT clause

I am not sure why we have the restriction of DEFAULT.  It is only used on
INSERT and the actual value will get transferred automatically.  We need to
review this, it looks like someone was being over cautious.

Ian