[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 |
233.0. "DDAL$TR_MON process aborts with a bugcheck dump" by ORAREP::KYOSS1::FERRARO (David Lazarus @kyo 323-4353) Mon Jul 29 1996 10:51
We have a system running Data Distributor. The DDAL$TR_MON process aborts
with a bugcheck dump immediately after it's created by DDAL$START_TR_MON.COM.
The dump file indicates a problem with the version of the transfer database.
It was working up until the beginning of July. This is the first time the
user has tried it since.
The system is running VAX/VMS V6.1
DDAL V6.0-0
DEC Rdb V6.0-0
Thank you,
Sue
------------
STARTUP PROCESS -
TSTMKO> @DDAL$START_TR_MON.COM USERC:[DDAL] USERC:[DDAL]
*** Transfer Database is USERC:[DDAL]DDAL$TR_DB
*** Transfer Monitor logfile is USERC:[DDAL]DDAL$TSTMKO_TR_MON.LOG
%RUN-S-PROC_ID, identification of created process is 60803C4D
Please wait a few moments before running RDO or
SQL to allow the transfer monitor to initialize.
LOGFILE USERC:[DDAL]DDAL$TSTMKO_TR_MON.LOG -
Copyright (c) 1986, 1994 by
Digital Equipment Corporation, Maynard, Mass.
Product version: DEC Data Distributor V6.0-0
logging is enabled for TIMESTAMP, PROCESS, ERROR, TRANSACTIONS, INTERRUPTS,
TRANSFERS, FAILURES
----- 26-JUL-1996 16:16:35.34 ----- PROCESS -------------------------
Process name: DDAL$TR_MON Priority: 5
Username: SYSTEM UIC: [VAXVMS,SYSTEM]
Nodename: TSTMKO PID: 60803C4D
Privileges currently enabled:
CMKRNL, CMEXEC, SYSNAM, GRPNAM, ALLSPOOL, DETACH, DIAGNOSE, LOG_IO, GROUP,
ACNT, PRMCEB, PRMMBX, PSWAPM, ALTPRI, SETPRV, TMPMBX, WORLD, MOUNT, OPER,
EXQUOTA, NETMBX, VOLPRO, PHY_IO, BUGCHK, PRMGBL, SYSGBL, PFNMAP, SHMEM,
SYSPRV, BYPASS, SYSLCK, SHARE, UPGRADE, DOWNGRADE, GRPPRV, READALL,
SECURITY
Image privileges:
Image name:
DSA72:[SYS1.SYSCOMMON.][SYSEXE]DDAL$TR_MON.EXE;5
----- 26-JUL-1996 16:16:35.53 ----- INTERRUPTS -------------------------
configuring complete; resuming (or beginning) normal operation
Maximum copy processes for this node set at 20
the transfer monitor is starting a bugcheck dump
DUMPFILE USERC:[DDAL]DDAL_BUGCHECK.DMP
================================================================
Bugcheck dump USERC:[DDAL]DDAL_BUGCHECK.DMP;77
================================================================
This file was generated by DDAL V6.0-0 upon detection of a fatal,
unexpected error. Please return this file with an SPR.
Circumstance under which the fatal error occurred:
%DDAL-E-WRONG_VER, version of transfer database is incorrect
-SYSTEM-S-NORMAL, normal successful completion
-NONAME-?-NOMSG, Message number 00006EC7
-ECWP-W-NORMAL, normal successful completion
Current date and time are 26-JUL-1996 16:16:38.19
================================================================
Stack Dump
================================================================
*** Symbollic routine names cannot be found though a ***
*** symbol table is present. Internal error ***
Base address of the DDAL image = 00000000
-------------------------------------------------------------------------------
REG# Contents: .REG [6] .REG [5] .REG [4] .REG [3] .REG [2] .REG [1] .REG [0]
R0 = 00000001
R1 = 00000000
R2 = 0000F762: 4C582120 4C582120 3A4C5821 203D2020 20305227 0000001C 00000003
R3 = 00013141: FB031362 B5000002 FAEF00FB 52FFFF14 98EF9E53 000003C3 EF9E000C
R4 = 7FEA2FDC: 00000000 0138806C 00000005 7FEA30F8 00000014 7FEA2FEC 00000003
R5 = 00000000
R6 = 0000F478: 73614220 2A303221 294B4341 54535F50 4D554424 244E4F4D 4D4F4312
R7 = 00013141: FB031362 B5000002 FAEF00FB 52FFFF14 98EF9E53 000003C3 EF9E000C
R8 = 00013141: FB031362 B5000002 FAEF00FB 52FFFF14 98EF9E53 000003C3 EF9E000C
R9 = 00019358: 50FFA19E 5108AC51 C351673C 571B0110 ACD1580C ACD05704 ACD001FC
R10 = 00004200: 442E4B43 45484347 55425F4C 4144445D 4C414444 5B3A4352 45535520
R11 = 0001A195: FF8FECEF 9E577FFE E4309F9E 58FFFF8F 9DEF9E59 000003C1 EF9E03FC
AP = 7FEA2F18: 0000ECBA 7FEA2FEC 00000014 00000001 00000000 00000000 00000000
SP = 7FEA2EDC: 00000000 00000000 00000001 00000001 00000000 00000000 7FEA2EDC
FP = 7FEA2EFC: 7FEA2FEC 7FEA2FA0 0000EC5A 7FEA2F30 7FEA2F5C 200C0000 00000000
-------------------------------------------------------------------------------
ARG# Argument: .ARG [6] .ARG [5] .ARG [4] .ARG [3] .ARG [2] .ARG [1] .ARG [0]
1 7FEA2FEC: 00000001 00004200 00000001 0126BE93 00000000 0138806C 00000005
2 00000014
3 7FEA30F8: 0001B22C 03C00000 00006EC7 00000001 00000000 0126C4E2 00000005
Handler = 0000E7DD, PSW = 0000, CALLS = 1, STACKOFFS = 0
Saved AP = 7FEA3078, Saved FP = 7FEA303C, PC Opcode = E9
SR2 = 7FEA30B0: 7FEA330C 7FEA3348 00000000 00000000 7FEA335C 7FEA3360 00000002
SR3 = 7FEA30F8: 0001B22C 03C00000 00006EC7 00000001 00000000 0126C4E2 00000005
SR4 = 00003B34: 00000000 00000000 00000000 00000000 00124670 00000001 00000000
SR5 = 00000000
SR6 = 00000059
SR7 = 00000001
SR8 = 00000001
SR9 = 00000001
SR10 = 00003B3C: 00000000 00000000 00000000 00000000 00000000 00000000 00124670
SR11 = 000004FC: 46534E41 52544553 41424154 41445F52 4546534E 41525424 4C414444
96 bytes of stack data from 7FEA2FDC to 7FEA303C:
7FEA30F8 00000014 7FEA2FEC 00000003 ....�/�.....�0�. 0000
0126BE93 00000000 0138806C 00000005 ....l.8......�&. 0010
00000001 00000001 00004200 00000001 .....B.......... 0020
00060112 00000001 000004FC 00003B3C <;..�........... 0030
00000000 00035AF0 0126C08A 000045FC �E...�&.�Z...... 0040
7FEA0030 00000030 0001C634 00000030 0...4�..0...0.�. 0050
Saved PC = 0000E5D0 : COMMON$$DUMP_STACK + 000007E0
-------------------------------------------------------------------------------
ARG# Argument: .ARG [6] .ARG [5] .ARG [4] .ARG [3] .ARG [2] .ARG [1] .ARG [0]
1 7FEA30F8: 0001B22C 03C00000 00006EC7 00000001 00000000 0126C4E2 00000005
Handler = 00000000, PSW = 0000, CALLS = 1, STACKOFFS = 0
Saved AP = 7FEA30A0, Saved FP = 7FEA3080, PC Opcode = D0
SR2 = 7FEA30B0: 7FEA330C 7FEA3348 00000000 00000000 7FEA335C 7FEA3360 00000002
SR3 = 7FEA30F8: 0001B22C 03C00000 00006EC7 00000001 00000000 0126C4E2 00000005
SR4 = 00003B34: 00000000 00000000 00000000 00000000 00124670 00000001 00000000
SR5 = 00000000
SR6 = 00000059
SR7 = 00000001
SR8 = 00000001
SR9 = 00000001
SR10 = 00003B3C: 00000000 00000000 00000000 00000000 00000000 00000000 00124670
SR11 = 000004FC: 46534E41 52544553 41424154 41445F52 4546534E 41525424 4C414444
8 bytes of stack data from 7FEA3078 to 7FEA3080:
7FEA30F8 00000001 ....�0�. 0000
Saved PC = 0001C105 : DDAL$$SHOW + 00000019
-------------------------------------------------------------------------------
ARG# Argument: .ARG [6] .ARG [5] .ARG [4] .ARG [3] .ARG [2] .ARG [1] .ARG [0]
1 7FEA30F8: 0001B22C 03C00000 00006EC7 00000001 00000000 0126C4E2 00000005
2 7FEA30E0: 00000005 05000001 000DD1E8 00000001 00000001 7FEA3390 00000004
3 7FEA30B0: 7FEA330C 7FEA3348 00000000 00000000 7FEA335C 7FEA3360 00000002
Handler = 00000000, PSW = 0000, CALLS = 1, STACKOFFS = 0
Saved AP = 7FEA30D4, Saved FP = 7FEA30BC, PC Opcode = 04
SR2 = 00000059
SR3 = 7FEA32A3: 20202020 20455341 42415441 445F5245 46534E41 5254244C 41444400
SR4 = 00000000
28 bytes of stack data from 7FEA30A0 to 7FEA30BC:
7FEA30B0 7FEA30E0 7FEA30F8 00000003 ....�0�.�0�.�0�. 0000
7FEA335C 7FEA3360 00000002 ....`3�.\3�. 0010
Saved PC = 00005FC7 : DDAL$$TR_MON_SET_QIO_AST + 00000654
-------------------------------------------------------------------------------
ARG# Argument: .ARG [6] .ARG [5] .ARG [4] .ARG [3] .ARG [2] .ARG [1] .ARG [0]
1 7FEA30F8: 0001B22C 03C00000 00006EC7 00000001 00000000 0126C4E2 00000005
2 7FEA30E0: 00000005 05000001 000DD1E8 00000001 00000001 7FEA3390 00000004
***** Exception at 00006EC7 : DDAL$$ACTION_START_TRANSFER + 000000B9
%DDAL-E-WRONG_VER, version of transfer database is incorrect
-SYSTEM-S-NORMAL, normal successful completion
-NONAME-?-NOMSG, Message number 00006EC7
-ECWP-W-NORMAL, normal successful completion
Handler = 00000000, PSW = 0000, CALLS = 0, STACKOFFS = 0
Saved AP = 7FEA3348, Saved FP = 7FEA330C, PC Opcode = 05
572 bytes of stack data from 7FEA30D0 to 7FEA330C:
7FEA30E0 7FEA30F8 00000002 8959F64D M�Y.....�0�.�0�. 0000
00000001 00000001 7FEA3390 00000004 .....3�......... 0010
0126C4E2 00000005 05000001 000DD1E8 ��..........��&. 0020
03C00000 00006EC7 00000001 00000000 ........�n....�. 0030
00124988 00000004 00000016 0001B22C ,�...........I.. 0040
41445F52 4546534E 41525424 4C414444 DDAL$TRANSFER_DA 0050
7F202020 20202020 20204553 41424154 TABASE . 0060
445F5245 46534E41 5254244C 41444459 YDDAL$TRANSFER_D 0070
20202000 00000459 20455341 42415441 ATABASE Y.... 0080
00000000 00000000 00000001 00000001 ................ 0090
00000000 00000000 00000000 00000000 ................ 00A0
(3 duplicate lines)
7FEA31CE 7FEA32CC 0002000A 00003290 .2......�2�.�1�. 00E0
00020001 00000001 0126C31A 00000000 .....�&......... 00F0
00000000 00000000 00000001 00000001 ................ 0100
00000000 00000000 00000000 00000000 ................ 0110
(3 duplicate lines)
0126C31A 00003B1C 00000B14 00060AB4 �........;...�&. 0150
00000B14 00060AB4 00000003 0000FF92 ........�....... 0160
00000000 00000008 0126C31A 00003B1C .;...�&......... 0170
7FFEE3D0 00035AF0 00000000 00000000 ........�Z..��. 0180
00000001 7FEA330C 7FEA3348 0000A811 .�..H3�..3�..... 0190
00060AB8 02080018 001832F0 780084B7 �..x�2......�... 01A0
4546534E 41525424 4C414444 7FEA3276 v2�.DDAL$TRANSFE 01B0
20202020 20204553 41424154 41445F52 R_DATABASE 01C0
4546534E 41525424 4C414444 00202020 .DDAL$TRANSFE 01D0
20202020 20204553 41424154 41445F52 R_DATABASE 01E0
00000000 00003B1C 00035AF0 01202020 .�Z...;...... 01F0
54535953 244D4E4C 0000000C 7FEF0015 ..�.....LNM$SYST 0200
504F435F 58414D24 4C414444 00064D45 EM..DDAL$MAX_COP 0210
010E000A 03220053 5345434F 52505F59 Y_PROCESS."..... 0220
7FEA32E4 010E0015 7FEA32D8 �2�.....�2�. 0230
-------------------------------------------------------------------------------
No arguments
Handler = 00000000, PSW = 0000, CALLS = 1, STACKOFFS = 0
Saved AP = 7FEA33CC, Saved FP = 7FEA3390, PC Opcode = D0
SR2 = 7FFE5E40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SR3 = 00003A00: 00004244 5F525424 4C414444 5D4C4144 445B3A43 52455355 00000001
SR4 = 00000474: 20656854 202C4843 5444544F 4E2D572D 4C414444 00000470 010E0003
SR5 = 0000FDD4: 08AE9F5E DD04AE54 097857FF FF451FEF 08C15456 7D5E08C2 00FC8FBB
SR6 = 00060000: 00000000 00100206 0000000A 00060B7C 000615B0 000615B0 00140204
SR7 = 0000000A
SR8 = 000066EB: 9E04AE03 2200048F D05E38C2 52000191 D6FF9E53 0126C33A 8FD0000C
SR9 = 7FEFDC80: EFDC2C00 00000000 0000007F EFDC2C7F EFDC5800 0000007F EFE2F000
SR10 = 7FEFDD3E: 02400020 0103007F 00687FFE 26847FEF DDB80004 30343533 32334238
SR11 = 7FEFDD0A: DC2C0040 00307FEF E4747FEF DC580000 00000000 00043130 30303030
72 bytes of stack data from 7FEA3348 to 7FEA3390:
00000000 00000000 00060000 00000000 ................ 0000
0A5A9FA0 00000000 0001BB5A 00000000 ....Z�........Z. 0010
7FEA3350 7FEA3364 00040008 00977E4A J~......d3�.P3�. 0020
00000000 7FEA3350 7FEA334C 00030004 ....L3�.P3�..... 0030
00000400 89E6CE30 0��..... 0040
Saved PC = 00005F01 : DDAL$$TR_MON_SET_QIO_AST + 0000058E
-------------------------------------------------------------------------------
ARG# Argument: .ARG [6] .ARG [5] .ARG [4] .ARG [3] .ARG [2] .ARG [1] .ARG [0]
1 7FFE5E3C: 00000000 00000000 00000000 00000000 00000000 00000000 00005E00
2 89625FFE: DD00DD0F FCF7117F FEDF409F 6EFA01DD 50DD0450 00038822 8FD00000
3 7FFE5E0C: FFFFFFFF FFFFFFFF 00000101 35303230 00A80000 00580044 003000B8
4 7FFE5EC4: 7FFE5EE1 00000030 00000000 00000000 00000020 00000000 001C004C
5 01000028
6 00000000
Handler = 00005FA8, PSW = 0000, CALLS = 1, STACKOFFS = 0
Saved AP = 7FFE5E00, Saved FP = 7FEA33EC, PC Opcode = E9
SR2 = 7FFE5E40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SR3 = 7FFE5EC4: 7FFE5EE1 00000030 00000000 00000000 00000020 00000000 001C004C
SR4 = 8B2D5080
SR5 = 7FF69C00: 00000B77 000000D8 000000C4 00000067 00000000 FFFFFFFF FFFFFFFF
SR6 = 89E6CE30
SR7 = 00000400: 00202020 20202020 20202020 20202020 20202020 20202020 20202020
SR8 = 00000000
SR9 = 7FEFDC80: EFDC2C00 00000000 0000007F EFDC2C7F EFDC5800 0000007F EFE2F000
SR10 = 7FEFDD3E: 02400020 0103007F 00687FFE 26847FEF DDB80004 30343533 32334238
SR11 = 7FEFDD0A: DC2C0040 00307FEF E4747FEF DC580000 00000000 00043130 30303030
32 bytes of stack data from 7FEA33CC to 7FEA33EC:
7FFE5E0C 89625FFE 7FFE5E3C 00000006 ....<^�.�_b..^�. 0000
00000000 00000000 01000028 7FFE5EC4 �^�.(........... 0010
-------------------------------------------------------------------------------
ARG# Argument: .ARG [6] .ARG [5] .ARG [4] .ARG [3] .ARG [2] .ARG [1] .ARG [0]
1 7FFE5EC4: 7FFE5EE1 00000030 00000000 00000000 00000020 00000000 001C004C
2 00000000
3 003000B8: 00035BA0 00035F20 00036058 00035F10 00035B20 00035F28 00035FE8
4 00580044
5 00A80000
6 35303230
7 00000101
8 FFFFFFFF
9 FFFFFFFF
10 00000000
11 01000028
12 121FD260
Handler = 89626015, PSW = 0000, CALLS = 0, STACKOFFS = 0
Saved AP = 7FFE5E00, Saved FP = 00000000, PC Opcode = 02
-------------------------------------------------------------------------------
================================================================
GETSYI Information
================================================================
SYI$_ARCHFLAG = 000038F0
SYI$_BOOTTIME = 11-JUL-1996 14:01:43.23
SYI$_CLUSTER_MEM= 144. SYI$_CLUSTER_NOD= 3.
SYI$_CPU = 11. SYI$_HW_MODEL = 2146053776.
SYI$_HW_NAME = "VAX 6000-430" SYI$_NODENAME = "TSTMKO"
SYI$_NODE_SWTYPE= "VMS " SYI$_NODE_SWVERS= "V6.1"
SYI$_SID = 0B000006 SYI$_VERSION = "V6.1 "
================================================================
GETJPI Information
================================================================
JPI$_ACCOUNT = "530 V0" JPI$_APTCNT = 0.
JPI$_ASTACT = 0. JPI$_ASTCNT = 198.
JPI$_ASTEN = 15. JPI$_ASTLM = 200.
JPI$_AUTHPRI = 4. JPI$_AUTHPRIV = FFFFFFFF:FFFFFFFF
JPI$_BIOCNT = 100. JPI$_BIOLM = 100.
JPI$_BUFIO = 45. JPI$_BYTCNT = 34640.
JPI$_BYTLM = 34640. JPI$_CLINAME = "DCL"
JPI$_CPULIM = 0. JPI$_CPUTIM = 178.
JPI$_CURPRIV = FFFFFFFF:FFFFFFFF JPI$_DFPFC = 64.
JPI$_DFWSCNT = 1033. JPI$_DIOCNT = 100.
JPI$_DIOLM = 100. JPI$_DIRIO = 31.
JPI$_EFCS = E3000001 JPI$_EFCU = 00000000
JPI$_EFWM = DFFFFFFF JPI$_ENQCNT = 1869.
JPI$_ENQLM = 2000. JPI$_EXCVEC = 7FFEFE34
JPI$_FILCNT = 92. JPI$_FILLM = 100.
JPI$_FINALEXC = 7FFEFF28 JPI$_FREP0VA = 003C3400
JPI$_FREP1VA = 7FEA0A00 JPI$_FREPTECNT = 264548.
JPI$_GPGCNT = 746. JPI$_GRP = 1.
JPI$_IMAGECOUNT = 0.
JPI$_IMAGNAME = "DSA72:[SYS1.SYSCOMMON.][SYSEXE]DDAL$TR_MON.EXE;5"
JPI$_IMAGPRIV = 00000000:00000000 JPI$_JOBPRCCNT = 0.
JPI$_LOGINTIM = 26-JUL-1996 16:16:34.70
JPI$_MASTER_PID = 60803C4D JPI$_MEM = 4.
JPI$_MODE = 0. JPI$_MSGMASK = 0000000F
JPI$_OWNER = 0. JPI$_PAGEFLTS = 1966.
JPI$_PAGFILCNT = 16779. JPI$_PAGFILLOC = 03000000
JPI$_PGFLQUOTA = 20000. JPI$_PHDFLAGS = 00000086
JPI$_PID = 60803C4D JPI$_PPGCNT = 1509.
JPI$_PRCCNT = 0. JPI$_PRCLM = 16.
JPI$_PRCNAM = "DDAL$TR_MON" JPI$_PRI = 4.
JPI$_PRIB = 4. JPI$_PROCPRIV = FFFFFFFF:FFFFFFFF
JPI$_SITESPEC = 00000000 JPI$_STATE = 0000000E
JPI$_STS = 00140001 JPI$_SWPFILLOC = 00000000
JPI$_TERMINAL = "" JPI$_TMBU = 0.
JPI$_TQCNT = 10. JPI$_TQLM = 10.
JPI$_UIC = [1,4] JPI$_USERNAME = "SYSTEM "
JPI$_VIRTPEAK = 10452. JPI$_VOLUMES = 0.
JPI$_WSAUTH = 2062. JPI$_WSAUTHEXT = 110004.
JPI$_WSEXTENT = 110004. JPI$_WSPEAK = 2255.
JPI$_WSQUOTA = 2062. JPI$_WSSIZE = 2983.
******* End of bugcheck dump file *******
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 233.1 | What to look for | BROKE::PROTEAU | Jean-Claude Proteau | Mon Jul 29 1996 12:11 | 19 |
| Sue,
The error message means that DDD's transfer monitor image,
DDAL$TR_MON.EXE, thinks that the transfer database is not the correct
flavor.
Have the customer examine the database and look at the
DDAL$TRANSFER_DATABASE table, column DDAL$TRANSFER_DATABASE_REVISION.
For DDD 6.0, the revision number should be 5. If you see a different
number, it indicates something is amiss with that database. If you do
see a 5, the next thing to do is check the version of the transfer
monitor image. Use ANALYZE/IMAGE to determine that. Somewhere in the
output of the ANALYZE command one sees the product name and version
number. Obviously if they don't have version 6.0 of the transfer
monitor, they have the wrong version of our software.
Let me leave it at that for now until further evidence is had.
Claude
|
| 233.2 | DDAL$TRANSFER_DATABASE_REVISION is 4 | ORAREP::KYOSS1::FERRARO | David Lazarus @kyo 323-4353 | Mon Jul 29 1996 13:49 | 33 |
|
Claude,
Thank you for the quick response. It is greatly appreciated.
>Have the customer examine the database and look at the
>DDAL$TRANSFER_DATABASE table, column DDAL$TRANSFER_DATABASE_REVISION.
SQL> select DDAL$TRANSFER_DATABASE_REVISION from DD.DDAL$TRANSFER_DATABASE;
DDAL$TRANSFER_DATABASE_REVISION
4
1 row selected
>For DDD 6.0, the revision number should be 5. If you see a different
>number, it indicates something is amiss with that database.
Do you know what might have happened? Is it possible to correct the
problem?
The system is running:
Image Identification Information
image name: "DDAL$SHR"
image file identification: "DDAL V6.0-0"
link date/time: 26-JAN-1994 22:00:20.57
linker identification: "05-05"
Thanks again,
Sue
|
| 233.3 | My guess | BROKE::PROTEAU | Jean-Claude Proteau | Mon Jul 29 1996 14:28 | 36 |
|
Well, it appears that the transfer database is wrong, doesn't it. What
might have happened? I'll list the possibilities I can think of,
without commenting on their likelihood:
1) Someone removed the disk containing the transfer database and restored
and older disk in its place. Revision 4 of the transfer database
structures corresponds with Data Distributor versions 5.1 all the way
back to version 2.2.
2) You said Data Distributor ran fine until sometike in July. If the
customer just happens to have installed Data Distributor version
6.0 then (you didn't say one way or the other, though I presume
no), they might have forgotten to run the DDAL$CONVERT_TR_DB.COM
procedure to convert from version 5.1 DDD format to version 6.0.
If they have been running fine under DDD version 6.0 until
recently, then this is not the cause.
3) Someone ran an old copy of the transfer database conversion
procedure, DDAL$CONVERT_TR_DB.COM, one that was shipped with, say,
Data Distributor version 5.1. This would seem very unlikely to me.
You could have the customer check the date on that file to see if
it seems a lot earlier than the other files that came with the 6.0
kit.
4) Someone modified the revision field in the database. Highly
unlikely.
I would start off assuming that they really are looking at a transfer
database that was last used under DDD 5.1. Since that was probably
some months (years?) back, they could use SQL to attach to the database
and look at some of the date fields in the status table. That will
give them an idea of how old the database is. My guess is that they
somehow have gotten an old one restored on their system.
Claude
|
| 233.4 | No comment | BROKE::PROTEAU | Jean-Claude Proteau | Mon Jul 29 1996 14:29 | 3 |
|
OK, so I lied. I did comment on their likelihood. Can't a fella
change his mind? :-)
|
| 233.5 | All comments are welcome. | ORAREP::KYOSS1::FERRARO | David Lazarus @kyo 323-4353 | Mon Jul 29 1996 15:57 | 15 |
|
Claude,
I think that number 1 is the most likely. We did a RMU/BACKUP of
the transfer database and created a new one using the DDAL$CREATE_TR_DB
procedure. We are now able to successfully start DDAL.
I'll be speaking with the user about restoring a good file.
Thanks for all your help.
Regards,
Sue
|