1.  Win 98 and 16 bit colour settings.
2.  S3 video cards or the like, graphics acceleration or graphics
device drivers.
3.  IDAPI32.cfg settings
4.  Multiple BDEs on the machine (single BDE on machines)
5.  Which Windows OS, although NT seems to be less affected.
6.  Oracle (other machines attached to the same server work)
7.  BDE version
8.  Memory issues.
9.  Paging file.
10. Filehandles
11. Network setup
12. Delphi version
13. The query
14. Oracle IP settings.

The only thing that sometimes seems to cure the problem is an OS
re-install.  Uninstalling and reinstalling the BDE / Oracle client /
App made no difference.  The app is built on a Windows NT v4.0 SP 4
machine - although I gather DB apps built on 95 and 98 have suffered
the same problem.  It seems to happen more on laptops, and it seems to
be BDE related.

So why does this problem happen, and what has Borland done about the
numerous reports of similar unexplained{*word*154} problems?

Any suggestions would be greatly appreciated.

Do all computers have 100% identical configurations?

Are they all the same brand and model?  This
seems unlikely but I have had weird problems
with one computer that go away simply by
putting the Hard Drive into another computer.

Have you considered Direct Oracle Access.
Reports on its quality seem consistent.

Graham Wood - gdW fleetWare

DB engines do a lot of concurrency management. If I had to give a bet on
a bug in a concurrent system resulting in an unexplained hang, it would
normally be as a result of a subtle threading or synchronisation
problem, perhaps a race condition. It may be a flaw in the BDE, or
possibly some common design flaw in the Win32 kernels, or some
interaction of both. If it appears to happen at random or at unexplained
intervals, and there doesn't seem to be a common cause, then this is a
good candidate.

I've seen stuff like this before: I've got a 32 bit twain driver that
works OK under 95 and 98, but mysteriously hangs for 2 minutes on
initialisation under NT. I assume it's waiting for some mutex, and
eventually times out and fails. I've also seen some concurrent systems
that I've written myself work fine on 99% of machines, and do odd stuff
on the remaining 1%, normally due to idiosyncracies in timing /
scheduling issues. If laptops seem to be worse behaved, then I'd not be
surprised if some slight difference in interrupt handling / priorities /
timing, and memory management architecture was causing this problem to
come to light.

My suggestion: See if you can get your app tested on a multiprocessor
machine running NT with the multiprocessor kernel. If the behaviour is
measurably different on that then that's another pointer.

My next suggestion is to get a copy of SoftICE. (WinICE). It's a Kernel
Mode device driver debugging tool, and it really lets you get into the
guts of things. It's not cheap, but if your company could afford a
single user license, it would probably help you track knotty problems
like this and repay itself in time.

Possible cures? hrmmmmph... you probably don't have the source to modify
things at the low level required. If you do find the problem, and you
find a cunning way of patching the binary, then go for it.... you will
earn huge amounts of kudos from the technically competent, and major
grief from the legal department!

Problems like this are as hard to find as the proverbial {*word*269} in a
{*word*275} house. <g> Best of luck!

MH.