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

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

They are running 7.2.1

Ray,

Have all the patches been applied?

Sean

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

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

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

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

FS1003 can occur when you try and look at a UD3 file with a 2.1 driver…

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

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

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

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

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

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.

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

Sean,

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

Ray

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

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 from the temporary file.

Sean

Or rename the temporary file after deleting the old corrupt file :)

… 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 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

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

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

=== At 09 MAY 2007 08:30PM [email protected] wrote: ===

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?

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

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

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

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

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

Umm… don't know

call me - I have 3.x here

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

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.

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

Bill

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.

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.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

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

View this thread on the Works forum...