[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dec_data_distributor

Title:The Replication Option for Rdb
Notice:Product renamed to Replication Option for Rdb
Moderator:BROKE::PROTEAU
Created:Wed Mar 02 1994
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:287
Total number of notes:1231

223.0. "%RDB-E-INVALID_BLR error during a replication transfer from RDB to ORACLE (see note 202)" by ORAREP::LEMAN::NAUFFRAY () Thu Jun 20 1996 10:26

Hi,

   Even after installing the last DDD 6.0 official version, I still have the
folllowing failure :


%DDAL-E-ERRACCDSTDB, error occurred accessing the destination database
-DDAL-E-SUPP, %RDB-E-INVALID_BLR, request BLR is incorrect at offset 101
-DDAL-E-SUPP, -DBI-I-CTXVAR_EXISTS, Context variable 0 previously declared at
 BLR offset 191


when trying to operate a replication transfer from RDB to Oracle in this
context :


	- Source database machine VAX/VMS V6.1 hosting RDB
	- Target database machine INTEL/NT     hosting Oracle7 Server 7.1.3.2.0 
	- DBI gateway for Oracle V3.1-02A working with SQLNET 1.2 client on VMS
	- DDD V6.0

	- The access to Oracle database through  SQL/RDB  works fine.
	- The access to Oracle database through the DBI GTW ORACLE works fine.
	- The Initial Replication transfert works fine.

   But :
	- The Update Replication transfert fails at BLR errors.

        That means only extraction transfers are able to work in this context,
        but not replication transfers.



  The last answer given about this problem was in the note Number 202.1      
in this conference, and advised to install the last DDD 6.0 official version
to solve the problem.

  I installed the preconised version (VMS distrib. December 95), but I've still
the problem.
  
  Is there a patch to apply or a workaround existing ???

  Thanks for the answer to this issue to be solved urgently.
  
  James
T.RTitleUserPersonal
Name		DateLines
223.1Information We Need to Investigate FurtherBROKE::PROTEAUJean-Claude ProteauThu Jun 20 1996 11:0529
    James,
    
    Just checking:  the latest official DDD 6.0 version you have is
    V6.0-11, correct?  That is the version now available through Oracle.
    
    Your problem sounds identical to a problem we fixed more than a year
    ago.  The correction ought to be in the V6.0-11 kits.  If you installed
    that version and the problem is as you've shown, either (1) this is a
    different manifestation of the same type of problem, or (2) we failed
    to incorporate the fix somehow.
    
    To help us get to the bottom of this, please do two things:
    
    (1) Examine the transfer log file and find the version number of DDAL
        listed.  Please confirm that it is version V6.0-11.
    
    (2) Run the failing transfer with BLR dumping enabled.  This will give
        us a printout of the BLR request that is causing the error.  To do
        this,
    
    	(a) Edit the LOGIN.COM file for the VMS account used to execute the
            transfer.  Insert the statement $ DEFINE RDMS$DEBUG_FLAGS B
    
    	(b) Run the failing transfer, and confirm that you get the BLR
            error as you reported.
    
    	(c) Post the transfer log file showing the BLR printout.
    
    Claude
223.2Bad version ....ORAREP::LEMAN::NAUFFRAYFri Jun 21 1996 03:5718
Hi Claude,

   Thanks a lot for your quick answer.
   I think that there's no need to send you the BLR trace, because after a 
 quick look, I've seen that the DDAL version owned for the moment by
 customer is v6.0-0 instead of v6.0-11, which is correcting the problem,
 according to what you said.
   So, it's impossible in DEC CD VMS distrib. to find this version.
   As it's a critical issue for the customer, do you know how I could pick
 up this version rapidly. Could you please help me for that ?

   The customer bought DDD v6.0 before the official agreement between DEC and
ORACLE.

   Thanks a lot for your support, indeed,
   Cheers,

   James
223.3Stay TunedBROKE::PROTEAUJean-Claude ProteauFri Jun 21 1996 09:214
    
    I'm checking on this right away.  Waiting to hear from my manager.
    
    Claude
223.4OKBROKE::PROTEAUJean-Claude ProteauFri Jun 21 1996 11:179
    
    My manager said ok, provided that the customer purchased a support
    license through Digital.
    
    Meanwhile, I'm checking on where I can place the kit so that you can
    copy it from the Digital ENET.  I'll post a note as soon as I've found
    out.
    
    Claude
223.5Kits locationBROKE::PROTEAUJean-Claude ProteauSun Jun 23 1996 08:4520
    
    James,
    
    Here's a pointer to the V6.0-11 kits.  Again, it is alright to give
    these kits to your customer provided that the customer has a valid
    support license.
    
    Claude
    
    ORAREP""::DDAL$PUBLIC:  is the location of the kits.  There's a VAX and
    an Alpha VMS kit:
    
    The VAX kit:
    
    	DDAL060.A   DDAL060.B  DDAL060.C
    
    The Alpha kit (note the extra A in the names):
    
    	DDALA060.A  DDALA060.B  DDALA060.C
223.6Great !ORAREP::LEMAN::NAUFFRAYMon Jun 24 1996 06:028
Claude,


   Thank you very much for your precious help. I'll pick up the kits ASAP
 from the address you gave me.

   Kind regards,
   James
223.7V6.0-11 works for meBROKE::GREENWed Jul 10 1996 12:215
    I ran into the exact same problem using the Vax platform.
    
    DDD V6.0-11 fixed the problem for me.
    
    Don