I just left a client site on Friday, where I had to restore a file from a backup after a GFE occured. This site was just inhereted, so I am feeling my way around.

The file with the GFE has a 3mb .LK file and a 74mb .OV file. The DUMP shows a value of 18 in the SIZELOCK.

To me this doesnt look normal.

Could this be the cause of potential GFEs.

Would this sizelock setting stop the file expanding for more records.

What would cause the size lock to be 18.

Any suggestions for NORMALISEING this file.

I noticed that when updates are done to this file, it is locked using ALL, 01. Dont know why not single record lock/unlock.

Barry

Barry,

The sizelock being 18 is unusual. Reset the sizelock back to at least 1 (most likely 0), where no one is using the file (or when no one is logged in).

Then resize the file using the statement REMAKETABLE filename. That should put the balance back in the LK and OV parts of the file. This could take some time, and might not be necessary. Overtime the LO and OV parts will balance out if the sizelock is less than 2.

Since the sizelock is greater than 1 the file will not expand dynamically, like it should, so as to not develop a very large OV part.

It is possible your problem occured due to the fact that the OV part was so large that it caused the GFE.

The locking the whole file rather than the actual record (or row)… well if there is no reason for the file lock then switch to a record lock. Maybe the programmer did not understand the difference between the two. You just better be absolutly sure that the file lock is not needed or "you" will cause GFE's. I doubt that the file lock is necessary.

If a workstation is rebooted or the network connection otherwise terminated before the sizelock can be decremented you wind up with sizelocks gt 1.

Most likely users at some time in the past were getting frustrated by the file lock and rebooting their workstations. Unless you can find a valid reason for using a file lock vs a record lock, I would change it.

Thanks very much for the information which supported my tactics.

FYI the error was "record in wrong group" , Fix gfe for the group fixed it with the loss of only 1 record.

I didnt know about the REMAKETABLE. I will try it on the copy of the file I took and see if it makes a difference, and time it as well.

Thanks again

Barry

Mmm, I will check and see if I can get any users to own up to that bad habit

They do complain about network being slow…so it is suspect

Barry

With Windows, they can often just kill the session (close the DOS Window) without rebooting.

View this thread on the forum...