Yesterday and today we have been breaking into Debug in the program RELATER with the non-numeric data message. The SUP_DATA record does get saved, but a second COPY_DATA record created in post-save (I believe) does not. After I delete the SUP_DATA record, the user can reenter the same data and save it without any problem.
The file has one relational index, which I rebuilt twice yesterday. Today I was able to capture the following data from debug (Thanks Don Cochran where ever you are!). If anyone has has any ideas I would love to hear them.
Note: _=@FM RgD
!/1 is 2301000006122010000038 = !X Returning To The DEBUGGER… E Line 1 'RELATER'. !/2 is PROTECT.MFSnSI.MFSnRTP57²DICT.MFSnQUICKDEX.MFSnRTP57_DICT.DOC_DATA*CBITS_ _000065FFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31320.LK²7²DOC_DATA*CBITS²RTP57__00006
4FFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31321.LK²00048_000063FFFFFFJ:\CBITS\DATA\PROD\
TRAX\REV31322.LK00098DICT.MFSnQUICKDEX.MFSnRTP57²DICT.DOC_DATA*CBITS²²²_000065FF
FFFFJ:\CBITS\DATA\PROD\TRAX\REV31320.LK00054RTP57²_000064FFFFFFJ:\CBITS\DATA\PRO
D\TRAX\REV31321.LK00054RTP57²_000063FFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31322.LK²DO
C_DATA =
!/3 is 5 =
!/4 is BOT =
!/5 is RTP57²_00005EFFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31770.LK =
!/6 is DOC_DATA*SUPPORT_DCN*BOT =
!/7 is 1 =
!/8 is =
!/9 is Unassigned! =
!/-1 is 22010000038 =
!/-2 is =
!/-3 is 13 =
!/-4 is 11 =
!/-5 is Unassigned! =
Thanks,
Roy
Red Alert!
I just spent 6.5 hours rebuilding relational indexes yesterday afternoon and evening and it is still happening. The first transaction a user enters bombs and the following ones work fine. =
![]()
Roy
Well is has been a while since someone complained of this and when they did a helpful Revelation support person posted here :-
World Leaders in all things RevSoft
Thanks Sprez,
I did find that post when I first shecked in here.
We have been running 3.12 since May '97 and this is the first time that has happen since I arrived in Mar. 2000.
There is only one index on the file that seems to be the problem.
I have removed and rebuilt the index 3 times. I even rebuilt the indexes for the REV31320 file that showed up in the Debug dump shown on the first posting. It is needed and used and can not be romoved without considerable coding changes. Besides we will be converting to Oracle 'soon' and all our problems will go away then.
Any other insights into this problem would be greatly appreciated.
Roy
Variable 2, the file handle, seems very odd. This should be the handle for the target file.
Can you write a small program, open that file (which appears to be DOC_DATA) and compare the resultant variable to what you entered here?
I'm guessing this is an invalid handle, which is breaking somewhere in RTP57 (or RTP57A) and is returning an error in the innocent relater.
If the handle is invalid, we'll work on finding out how to solve that problem.
World Leaders in all things RevSoft
Just noticed your latest post…THANKS!
I'll try this first thing tomorrow 9:00 am Bush Standard Time
and should have something posted before afternoon tea.
![]()
Thanks again,
Roy in Wash DC
If afternoon tea starts at 3:00, I'm late, but anyway…
I wrote a program that opened the DOC_DATA file and then formatted the file handle and printed it out. The output is below. The only differences I could find are in the hex code/address before the 6 Fs and the single digit following the first directory path. I am still stumped and we are still breaking.
Roy
PROTECT.MFS
nSI.MFS
nRTP57
²DICT.MFS
nQUICKDEX.MFS
[email protected]_DATA*CBITS@tm@tm@tm ← @tm used for textmark
CR
00004BFFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31320.LK
²1 ← value changed
²DOC_DATA*CBITS
²RTP57@tm
CR
00004AFFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31321.LK
²00048
CR
000057FFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31322.LK00098DICT.MFS
nQUICKDEX.MFS
nRTP57
²DICT.DOC_DATA*CBITS
²
²
²
CR
00004BFFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31320.LK00054RTP57
²
CR
00004AFFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31321.LK00054RTP57
²
CR
000057FFFFFFJ:\CBITS\DATA\PROD\TRAX\REV31322.LK
²DOC_DATA
CR
We want to clear something up before going further. The index blows up the first time and works all other times. When you say first time, does this mean the first time per workstation or the first time for the day?
World Leaders in all things RevSoft
Sorry it has taken so long to reply, I was out of town for a week. The problem occurs on every workstation the first time the window is saved. It also occurs on our indexer.
Roy
What happens if you read/write an existing record as soon as you log on?
Does this file have any other MFS's besides SI.MFS?
World Leaders in all things RevSoft
If you read, modify, and then save a record it works fine. If you then try to add a new record it breaks in the RELATER subroutine.
The file has PROTECT.MFS as well as SI.MFS.
Roy