[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

265.0. "VINNOTFND ERROR - need advice" by ORAREP::EVER::LALIBERTE (PSG/IAE - OGO) Tue Feb 04 1997 16:38

    
    sorry if this has been asked elsewhere...we don't have the time
    to go thru all the notes!
    
    we have this error coming up trying to update our target
    production database:
    
    
    %DDAL-E-VINNOTFND, vintage TSER 000EBBEA was not found in the 
    source database
    
    any help is appreciated....
    
    thanks
    ----------------------------------------------------------------
   here is entire log:
    
    "SIGA$CLIENT_DB_GREAT1" = "GREAT1::DISK$REFDATA:[RUS.FINANCE]SIGA$DATABASE" (LNM$PROCESS_TABLE)

%DMQ-S-SETLNM, Set to DECmessageQ LNM table DMQ$LNM_0179_00257
$		! Restore VERIFY setting and split.
$ EXIT
$ SET VERIFY
$ SHOW = "SHOW"
$ RUN = "RUN"
$ LOGOUT = "LOGOUT"
$ SHOW PROCESS 

 4-FEB-1997 11:14:58.98   User: SIGA$SERVER      Process ID:   2022ECD6
                          Node: GEMINI           Process name: "DDAL_COPY_01   "

Terminal:           MBA9829:
User Identifier:    [SIGA$SERVER]
Base priority:      4
Default file spec:  SIGA$SERVER_ROOT:[SIGA_SERVER]
$ DEFINE DDAL$CP_CONTINUE "SUCCESS"
$ DEFINE/TRANS=TERMINAL DDAL$TRANSFER_NAME SIGA_DATABASE_GREAT1
$ DDAL$CP_ACTION :== U
$ DDAL$CP_RETRY_ITERATION == 00
$ RUN DDAL$COPY_PROCESS

Product version:	DEC Data Distributor V6.0-0

-----  4-FEB-1997 11:14:59.27 ----- Process         -------------------------
Process name:  DDAL_COPY_01                  Priority:  4                       
Username:  SIGA$SERVER                       UIC:  [SIGA$SERVER]                
Nodename:  GEMINI                            PID:  2022ECD6                     
Privileges currently enabled:
    TMPMBX, NETMBX

Image privileges:
    SYSPRV, BYPASS, SYSLCK, SECURITY

Image name:
    DSA34:[SYS4.SYSCOMMON.][SYSEXE]DDAL$COPY_PROCESS.EXE

Transfer database = DAT10:[DDAL]DDAL$TR_DB
Transfer name     = SIGA_DATABASE_GREAT1           
Transfer option   = U (Replication update transfer)

11:14:59  %DDAL-I-READTRDEF, reading the transfer definition from the transfer database
11:15:00  %DDAL-I-ATTACHSDB, attaching to source database SIGA$SERVER_ROOT:[SIGA_SERVER.DB]SIGA$DATABASE.RDB
11:15:01  %DDAL-I-ATTACHTDB, attaching to target database SIGA$CLIENT_DB_GREAT1
11:15:05  %DDAL-I-STADATTRM, starting data transfer/modification
-----  4-FEB-1997 11:15:11.63 ----- Error           -------------------------
%DDAL-E-VINNOTFND, vintage TSER 000EBBEA was not found in the source database

$ LOGOUT
  SIGA$SERVER  job terminated at  4-FEB-1997 11:15:12.18

  Accounting information:
  Buffered I/O count:             232         Peak working set size:    6447
  Direct I/O count:              2262         Peak page file size:     38008
  Page faults:                   8336         Mounted volumes:             0
  Charged CPU time:           0 00:00:05.48   Elapsed time:     0 00:00:18.10
T.RTitleUserPersonal
Name
DateLines
265.1BROKE::PROTEAUJean-Claude ProteauTue Feb 04 1997 17:1320
    
>    we have this error coming up trying to update our target
>    production database:
>    
>    %DDAL-E-VINNOTFND, vintage TSER 000EBBEA was not found in the 
>    source database
    
Such error messages are explained in the file SYS$HELP:DDAL$MSG.DOC.  It
means one of two things:

1) The source database is the wrong one.  Perhaps someone replaced the database
   files.

2) Someone manually deleted rows from the RDB$CHANGES table.

After a replication update transfer completes, information about the last
transaction that was processed is recorded in the target database.  The
next time the update transfer is run, a check is made to make sure that
last transaction still appears in the RDB$CHANGES table.  If it does not,
you get the error message you reported.