A client of mine doing data entry in a (single user) OI 3.3 app left her (non-networked) computer in the middle of entering a row. When she came back the screen saver had started. She pressed a key to close the screen saver, but the system hang. She had to re-boot her computer. After that she could not enter the same key that she used when she was interrupted. If she tried to enter that key she got the FS107 Read error for the window's table's OV file. We tried LH Verify, which reported a GFE, and LH Fix which fortunately seemed to fix the error.

I guess the GFE was caused by the abrupt termination of the app, but what about this screen saver hang business? Are OI apps and screen savers uneasy bedfellows? Or could the hang just as well have been caused by something altogether different?

- Oystein -

Oystein,

If it helps, I had the same problem, but simply whilst doing some development with OI 3.2

Somehow the screen saver being activated also wiped out some of the code I was designing at the time ? There were also similar problems when I used the 'power saver' function (it's not easy being green).

Therefore, I never use the screen saver or power saver anymore on the PC used for development. The clients that run the application both use screen savers though, and haven't reported any problems (believe me, they would call me if it happened).

Peter

I had to stop using my Simpsons screen saver as it caused OI to GPF and or GFE. Berkely Systems or whoever recommended that I upgrade to the 32 bit version but I figured I could live without it.

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

Oystein,

FWIW: The problem got so bad at our customer sites that our company had to take the position that we'll no longer support a customer that insists on using a screen saver (or at least, we'll be darn grumpy about fixing their GFEs).

I don't know what the problem is, but I've never found another way around it besides banning screen savers outright. The Simpson screen saver in particular seemed to cause a lot of problems, but it may just be that Homer and Bart were pretty popular guys back then.

As a general defensive measure, we've found that turning off Window's write-behind disk caching feature DRAMATICALLY reduced the number of GFEs, as well as eliminated instances of "lost" updates, even when there's complete system lockup. Running scandisk /fix from autoexec also helped, expecially after we modified our app to automatically run LH_verify() upon init for all tables in DATAVOL if scandisk actually had to fix something.

Hope this helps,

Andy Fekete

Organon Teknika

View this thread on the forum...