Conference orarep::nomahs::dec_data_distributor

Here's a reply I got from Shou-pin Yu:

Without an in-depth look at the problem , I would suggest to check a few
things:

1. the definition of the system logical name for the transfer database
2. whether the user can attach the transfer database using the logical
   name and do a SELECT on ROR tables.
3. if both are fine, then turn on dispatch debug flag so see if we can get
   more info as to what has transpired in attaching or accessing TR DB.

(LNM$SYSTEM_TABLE)

  "DDAL$TRANSFER_DATABASE" = "38_W2:[ROHR]DDAL$TR_DB"
  "DDAL_TRANSFER_DATABASE" = "38_W2:[ROHR]DDAL$TR_DB"

SQL> att 'f ddal$transfer_database';
SQL> select * from ddal_tnsf_status; 
 TRANSFER_NAME                      REINI_FLAG   TRANSFER_STATE   
   LAST_COMPL_STATUS   LAST_TRANSFER_TIME        STATE_CHANGE_TIME         
 ROR_TEST                                    0                4   
            19301275   17-NOV-1858 00:00:00.00   29-APR-1997 15:12:15.17   
 
1 row selected
    
    I have noted down that the DSP_DEBUG_FLAGS logical is defined in
    rdb$client(server)_defaults.dat. But those are only for remote access,
    I thought? Is this the correct place to define the dispatch debug?
    
    Thanks,
    Regina
                     

    
    Regina,
    
    I'm not certain where the debug flags should be set (I personally
    haven't had to do it often, so I forget).  Let's forget that idea for
    the moment and come back to it later if necessary.
    
    Remember that when the transfer is executed, the copy process is
    started up in a detached process running under your login account (you
    being the one who created the transfer definition).  Particularly in a
    multiversion Rdb environment, it is easy to forget to set things up
    correctly for a detached process.
    
    I suggest you try the following.  Modify your transfer definition to
    point to a prologue file (A DCL COM file of your own making).  For
    example,
    
    	ALTER TRANSFER transfer_name PROLOGUE FILE IS filename;
    
    Create a DCL COM file to invoke SQL.  Ask SQL to SHOW VERSION.  Then try
    to attach to the transfer database and do a select * from
    ddal_tnsf_status again.  I suspect the prologue will get an error,
    indicating that your environment is not properly set up for transfer
    execution.
    
    If this turns out to be the problem, take another look at the ROR 7.0
    handbook.  If you cannot find an explanation (something you missed),
    let me know.
    
    Claude

    Ahem, well it helps when you have the documentation on paper and not
    only on screen...
    
    I take the blame, but I guess DDAL could pass back the Rdb error
    message (which is pretty explicit in such cases).
    
    Thanks a bunch,
    Regina                                         

Regina,

In ROR V7.0, all data accesses to the Transfer Database are made through
the SQL interface, rather than the DSRI calls.  One impact of this change
is that we have no direct access to the Rdb message vector.  We can only
check SQLCODE to see if there is an error and to report its value.  If the
value is a negative number other than '-1', we can look up the table in
SQL manual to understand the nature of the error.  The value '-1' is a
'catch-all' SQL error code.  In this case, we need to look into the
circumstances to further determine the cause of an error.

Regards,

Shou-pin

You do have access to the message vector and you can get the message for the
log.

Ian