GFE and Fixing Group (OpenInsight 32-Bit) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"OpenInsight 32-Bit" author:"Ray Chan" author:"Sean FitzSimons" author:"support@sprezzatura.com" author:"Richard Hunt" author:"Warren Auyong" author:"Bill Reynaldos" author:"
rayc@symmetryinfo.com
" author:"Richard Bright" author:"Gerald Lovel" author:"Karen Oland"}}

[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]


==== GFE and Fixing Group (OpenInsight 32-Bit) ====
=== At 23 APR 2007 07:07:42PM Ray Chan wrote: ===
 
 
<QUOTE>
With OI, we rarely ever see a GFE. Thus, when I see one, it's like I'm out of shape and don't know how to fix it. I guess this is the good and bad.



A client's pc (single-user) would shut and start itself a number of times over a three day period while the user was in OI. This is bad as we know and supposedly fixed.



Now when I run I run the LH verify routine, it tells me that the file has GFEs, but when I click the Display Group or Display Statistics button, the Verify LH Table window locks up and doesn't do anything. Can't even close it. Have to use the task manager. Thus, I can't see what Group needs fixing.



I'm not sure, but is the GFE info stored in Syslhgroup? If  I clear the file and rerun the Lh Verify again, can I use this file to see where the GFEs are? Is the layout for records here defined somewhere?



Any suggestions or comments?



Thanks,

Ray Chan
</QUOTE>
----

=== At 24 APR 2007 08:07AM Sean FitzSimons wrote:  ===

<QUOTE>Ray,



This is a bug in OI.  It was fixed.  What version of OI is this occurring in?  I'm pretty sure the fix was in 7.2 or 7.2.1.



Sean

</QUOTE>

----

=== At 24 APR 2007 09:29AM Ray Chan wrote:  ===

<QUOTE>They are running 7.2.1

</QUOTE>

----

=== At 24 APR 2007 11:49AM Sean FitzSimons wrote:  ===

<QUOTE>Ray,



Have all the patches been applied?



Sean

</QUOTE>

----

=== At 24 APR 2007 02:00PM Ray Chan wrote:  ===

<QUOTE>I don't think all the 7.21 patches were applied.



If I apply the 7.22 upgrade, will that fulfill the requirement?



Thanks,

Ray Chan

</QUOTE>

----

=== At 25 APR 2007 03:08PM Sean FitzSimons wrote:  ===

<QUOTE>Ray,



Upgrading to 7.2.2 should be all you need.  If that still doesn't do it then install the patches.  You are able to install the patches in a 7.2.2



Sean

</QUOTE>

----

=== At 04 MAY 2007 01:17PM Ray Chan wrote:  ===

<QUOTE>When enter the Group to be fixed, I'm getting an error message FS 255. I upgraded their system to 7.2.2.



Any idea?



Sure would be nice to have the DUMP.



Ray Chan

</QUOTE>

----

=== At 06 MAY 2007 04:40PM Ray Chan wrote:  ===

<QUOTE>To all,

With regards to the FS255, I did some research and created the DUMP_FIX_TEMP.



Now when I select a Group to fix and click Fix GFE, I'm getting a FS1003 message. This doesn't look good.



Anyone care to give a guess what I should do. Thanks,

Ray Chan

</QUOTE>

----

=== At 06 MAY 2007 05:48PM support@sprezzatura.com wrote:  ===

<QUOTE>FS1003 can occur when you try and look at a UD3 file with a 2.1 driver...





support@sprezzatura.com

The Sprezzatura Group Web Site

[i]World Leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]

</QUOTE>

----

=== At 07 MAY 2007 10:39AM Ray Chan wrote:  ===

<QUOTE>What does it mean if the file is using the 2.1 driver and not the UD3.



We don't use the UD3 driver. Is there another patch?



Thanks,

Ray Chan

</QUOTE>

----

=== At 07 MAY 2007 11:23AM Sean FitzSimons wrote:  ===

<QUOTE>Ray,



What file is in error?  Is it a Revelation created file, one you created, one created by someone else?



A file created using the UD3 driver cannot be read using the 2.1 driver.  That's why I ask who created the file.



Sean

</QUOTE>

----

=== At 07 MAY 2007 12:32PM Ray Chan wrote:  ===

<QUOTE>It's a file created by us. This is not an RTI file.



Recap: I'm trying to fix some GFEs. Initially (based on your suggestion), I upgraded the system to 7.22. Then when I tried to fix the GFE, I got a FS255. After some research, it seems we may need to create a Dump_Fix_Temp. I created this file. Now when I try to fix the GFE, I'm getting the FS1003. I can look at the SYSLHVERIFY file and see that the bad groups might be 2936, 4984, 4985, 7032, & 7033. The user is able to work, but when doing certain things they will get a GFE message on their screen. Unfortunately, the user doesn't have a backup. They know that they may lose some data.



What suggestions do you or anyone have?

Thanks,

Ray Chan



Thanks,

Ray

</QUOTE>

----

=== At 07 MAY 2007 02:52PM Sean FitzSimons wrote:  ===

<QUOTE>Ray,



From the REVERROR.DAT file:



FS1003: Group Format Error: OS File : %1% Group # : %2% Invalid frame header during read.



This normally occurs when a file was created using the 3.0 driver and read using the 2.1.  There is no fixing this error.



Sean



</QUOTE>

----

=== At 07 MAY 2007 04:36PM Richard Hunt wrote:  ===

<QUOTE>I might be confused... I do believe I had a similar problem with using 3.0 and 2.1



If I remember correctly I fixed it by using "netdrv.exe" so as to go back to 3.0, and then exported the data from the file and deleted the file. Then I went back to 2.1 and created the file and imported the data.



That was before I had any problems with GFE's. I had just noticed that some of my files were 3.0 and I could not use the FIX_LH subroutine.

</QUOTE>

----

=== At 07 MAY 2007 05:20PM Sean FitzSimons wrote:  ===

<QUOTE>Richard,



You are correct.  The file cannot be fixed using FIX_LH but it can be dumped to 2.1 created intermediate file and then rewritten to a good 2.1 created file.



Sorry for any confusion.



Sean

</QUOTE>

----

=== At 07 MAY 2007 06:11PM Ray Chan wrote:  ===

<QUOTE>Sean,

Are you listening? We did not use the UD3 driver.



Ray

</QUOTE>

----

=== At 08 MAY 2007 08:09AM Sean FitzSimons wrote:  ===

<QUOTE>Ray,



The header is corrupt.  You need to copy the file to a new temporary file, delete the old file, create the file again and copy back to the temporary file.



Sean 

</QUOTE>

----

=== At 08 MAY 2007 08:42AM Sean FitzSimons wrote:  ===

<QUOTE>It should be:



The header is corrupt. You need to copy the file to a new temporary file, delete the old file, create the file again and copy back [b]from[/b] the temporary file.



Sean

</QUOTE>

----

=== At 08 MAY 2007 12:35PM Warren Auyong wrote:  ===

<QUOTE>Or rename the temporary file after deleting the old corrupt file :)

</QUOTE>

----

=== At 08 MAY 2007 10:30PM Ray Chan wrote:  ===

<QUOTE>[i]... You need to copy the file to a new temporary file, delete the old file, create the file again and copy back from the temporary file.[/i]



I was trying to create a table programatically using Create_Table so I could programmatically do a recordcopy of data from the "bad" table to the "new" table.



It looks very straightforward. However, for some darn reason, I'm getting a FS404.



I running OI7.22. 



In the process of playing with this, I see the Copy_Table function. Just curious, but does this do the equivalent of a recordcopy, i.e., select filename, than copy record.



Thanks,

Ray Chan



</QUOTE>

----

=== At 08 MAY 2007 10:49PM Ray Chan wrote:  ===

<QUOTE>Ok, I think I got the Create_Table to work . Sorry about that.



However, any response regarding Copy_Table would be helpful, i.e, is it the same as a Select and Recordcopy? 





Going home, thanks,

Ray

</QUOTE>

----

=== At 09 MAY 2007 09:41AM Bill Reynaldos wrote:  ===

<QUOTE>Hi Ray.  No, Copy_Table does not do a select/record copy, that would be Copy_Row if you were using an asterisk to select all rows to copy.



As a general caveat regarding creating tables programatically, etc. the user needs a development copy of OI.  Doing this with a runtime copy is a violation of the license agreement.

Bill

</QUOTE>

----

=== At 09 MAY 2007 08:30PM 
rayc@symmetryinfo.com
 wrote:  ===

<QUOTE>This doesn't look good. I copy the data to another table. Before starting I saw that the number of record was about 27,000. After I did the copy, I see about 10,600.



I'm guessing that either the count was initially wrong because of problem with the frame/header/whatever or something is inhibiting the copy of all records to the temporary file. Unfortunately, I think it's the latter.



I changed to an RLIST and I can see a Status Error msg of FS127,which points to a GFE, but that is my delimena. I can't fix the blooming GFE that's why I'm trying to copy the data to a temporarty file, but it doesn't look like it's letting me copy all the records.



Thank goodness this doesn't happen often, but now that it has, is there a fix?





</QUOTE>

----

=== At 10 MAY 2007 12:43AM Richard Bright wrote:  ===

<QUOTE>Ray,

What about a restore from backup tape. (You know - determine the dos .LK and .OV names of the data table; rename, then restore and copy in the two particular archived files.  Bay be a problem if there are relational indexes but...



Richard Bright 

</QUOTE>

----

=== At 10 MAY 2007 09:33AM Gerald Lovel wrote:  ===

<QUOTE>Bill,



For the purpose of creating a temporary table for data recovery Ray could copy an existing unindexed table to maybe datavol, attach the temporary table, clear it, and then copy the corrupted records to the temporary table.  This avoids the issue of using Make_Table or some such and the attendant questions of compiling dictionaries, correct?  It is my understanding that Copy_Table is entirely permitted in runtime.



Gerald

</QUOTE>

----

=== At 10 MAY 2007 10:08AM Ray Chan wrote:  ===

<QUOTE>Richard,

Well there are relational indexes.



The darn problem is that they don't have a current backup that's useable  ;-( Some lessons are learned the hard way. It seems the small users are less discipline in doing them and verifying if it is being done.



Thus, I'm trying to help them out since they're kind of stuck and need some help. I think a good DUMP would be useful here.



Ray Chan

</QUOTE>

----

=== At 10 MAY 2007 11:23AM Karen Oland wrote:  ===

<QUOTE>since it isn't a UD3 file, why not pull it into arev and fix it?

</QUOTE>

----

=== At 10 MAY 2007 11:58AM Ray Chan wrote:  ===

<QUOTE>I don't think I have AREV 3.x. This may be obvious, but can I take an OI file and fix it AREV 2.01. It's my OS/2 version 



Ray Chan

</QUOTE>

----

=== At 10 MAY 2007 12:25PM Karen Oland wrote:  ===

<QUOTE>Umm... don't know



call me - I have 3.x here

</QUOTE>

----

=== At 10 MAY 2007 06:45PM Ray Chan wrote:  ===

<QUOTE>Karen,

Thanks I may have to call you later. I'm having some other fires to attend to at the momement.



RTI or anyone: Do you know if files in OI can be attached by older versions of Arev?



Ray 

</QUOTE>

----

=== At 10 MAY 2007 10:43PM Warren Auyong wrote:  ===

<QUOTE>AFAIK it's only files created under the UD drivers that have incompatible headers with ARev. Arev should only have version 1.0 and 1.1 LH files. At least I don't think there were more versions than that in ARev. Aaron could probably answer that off the bat.



Don't attach the dictionaries and give it a try. The OI Engine has it's origins from the OS/2 version as I recall.

</QUOTE>

----

=== At 11 MAY 2007 09:04AM Bill Reynaldos wrote:  ===

<QUOTE>Hi Gerald.  Yes, you are correct, Copy_Table is permitted in a runtime.



Bill

</QUOTE>

----

=== At 13 MAY 2007 05:15AM Richard Bright wrote:  ===

<QUOTE>Ray,

If local resources need additional support - I know that Revelation (for a moderate fee) will have a look at the table and endevour to do a recovery.  I had an experience where site had corrupted the Header frame and (If I recall right) didnt have good backup regieme.  Rev were exceptionally helpful.

I know that you said that there were relational indexes involved - my suggestion is that you first secure what you can simply recover - then work up from there - irrespectively I expect there to be data loss.  The aim is to reduce or minimise the loss.

</QUOTE>

----

=== At 17 MAY 2007 04:50AM support@sprezzatura.com wrote:  ===

<QUOTE>If you install the UD client into AREV, it will read and write UD header type files.  However, it won't handle records over 64K and DUMP will report an error on a corrupted frame 0.  Don't fix it.  Otherwise, you should be able to fix other groups.



support@sprezzatura.com

The Sprezzatura Group Web Site

[i]World Leaders in all things RevSoft[/i]

[img]http://www.sprezzatura.com/zz.gif[/img]

</QUOTE>

----

=== At 20 MAY 2007 04:31PM Ray Chan wrote:  ===

<QUOTE>Thanks to all that responded. First it's good to know that there is a support network here. What would we do without it.



To bring all up to date on this situation, we finally fixed the GFEs which we couldn't fix using OI 7.22.



We fixed the GFEs by downloading the REV files to our system. As I mentioned, we don't have a running version of AREV 3.x readily available. However, we have a copy of AREV OS/2 2.01 running on a Windows 2000 PC. Fortunately, the DUMP facility worked on the OI files. We're not using UD.



It took a few minutes to remember how to use dump. Thank goodness, I haven't forgotten everything. In my research, I remember reading about a DUMP utility in the recent March 2007 issue of Sprezzatura's Electronic Newsletter. I revisited that article by Aaron Kaplan. Whenever the Utility is available, I can see that it will be essential item to have in our OI toolkits. From my point of view, I don't want to have to rely on AREV to fix problems within OI.



Again, thanks to all, meanwhile for other developers if you're in a pinch AREV 2.x should work as well as AREV 3.x.



Ray Chan



</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=6E6B009C95A999E4852572C6007F0C78|View this thread on the Works forum...]]