[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 265.1 |  | BROKE::PROTEAU | Jean-Claude Proteau | Tue Feb 04 1997 17:13 | 20 | 
|  |     
>    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.
 |