When you fix GFEs with OI, how do you know which rows you lost? (OpenInsight Specific)
At 14 OCT 1998 08:22:20AM Oystein Reigem wrote:
When you fix GFEs with OI, how do you know which rows you lost? I seem to remember it was easy to examine in Arev but that I never found out how in OI.
- Oystein -
At 14 OCT 1998 06:52PM Matt Crozier wrote:
You can usually work this out by examining the records in DUMP_FIX_GARBAGE. Don't know if there is an easier way in OI.
Matt.
At 15 OCT 1998 04:18AM Oystein Reigem wrote:
Matt,
Thank you!
You made me look again for DUMP_FIX_GARBAGE, and now I realized the reason I didn't find it was I haven't got DATAVOL attached! (The same probably goes for our clients.) I thought it didn't exist because I hadn't done any LH fixing. But it was there all right with some really old stuff in it. We haven't got any data tables in DATAVOL, and at one point we might have detached it.
I haven't got any GFEs myself at the moment (cross my fingers), but what do you think would happen if I had GFEs now and tried to fix them? Would LH Fix attach DUMP_FIX_GARBAGE? And detach it afterwards?
And should one always clear out DUMP_FIX_GARBAGE before one does an LH Fix? Or does LH Fix do that for you?
Sorry to bother you with all these trivial questions, but we're in one of the terra incognita's of my OI/Arev knowledge, and the answers would be of great help for me.
What's in DUMP_FIX_TEMP, by the way? (Ooops - there goes another question, but I cannot find this in the OI online help, and I've mislaid my Arev manuals…)
![]()
- Oystein -
At 15 OCT 1998 06:03PM Matt Crozier wrote:
Funny that - we've got the same problem, ie DATAVOL not being attached by default. I'm not sure how this happened but we just reattached it and then re-DEFINE_DATABASEd it. We also found that VERIFY_LH wouldn't work unless DATAVOL was attached with these files! So I've always ATTACH_TABLE DATAVOL before doing either FIX_LH or VERIFY_LH to fix GFEs.
I believe FIX_LH will clear out DUMP_FIX_TEMP and DUMP_FIX_GARBAGE first. When fixing a group, the good records are copied into DUMP_FIX_TEMP, the rest is put in DUMP_FIX_GARBAGE, the group is then reset and the good records copied back from DUMP_FIX_TEMP.
Matt.
At 16 OCT 1998 04:49AM Carl Pates wrote:
Matt, Oystein
AFAIK I think you just create the two DUMP_FIX tables in your app and Fix_LH etc will use those. I don't think you need to attach the ones in DATAVOL if you don't want to. In early versions of OI I've also known the system create these two files in the app if they weren't there but I'm not sure if does this now.
![]()
cpates@sprezzatura.com
World Leaders in all things RevSoft
At 16 OCT 1998 09:00AM Oystein Reigem wrote:
Matt,
Funny that - we've got the same problem, ie DATAVOL not being attached by default. I'm not sure how this happened but we just reattached it and then re-DEFINE_DATABASEd it.
Here I think it might have happened at the time we deleted the Datavol directory (because we thought we didn't need it). Later we put it back but probably forgot to attach and redefine the db. Or something.
We also found that VERIFY_LH wouldn't work unless DATAVOL was attached with these files!
I certainly think it has worked here, even when DATAVOL wasn't attached. I must admit that at one point we did have definite problems with LH Verify, but I put that in the bag with the symptoms we had with in the collation sequence. (LH Verify seemed to run but didn't report back what it found.)
So I've always ATTACH_TABLE DATAVOL before doing either FIX_LH or VERIFY_LH to fix GFEs.
I believe FIX_LH will clear out DUMP_FIX_TEMP and DUMP_FIX_GARBAGE first.
Then I choose to believe it too. It's not a matter of life and death this time.
![]()
When fixing a group, the good records are copied into DUMP_FIX_TEMP, the rest is put in DUMP_FIX_GARBAGE, the group is then reset and the good records copied back from DUMP_FIX_TEMP.
Thanks for the help and info!!
- Oystein -