Okay ladies and gentlemen here is my problem,

We moved our Paradox system from Novell 6.x to Windows 2003 (clustered
environment).
Ever since then the system has been experiencing lockups and freezes. I
added the "Oplocks" disable and the other setting in registry (lanmanserver)
just as I have read to do. I changed the BDE to be LOCAL SHARE = TRUE.
This was done for both servers in the 2 node cluster.

Users will work for about 1.5 hours or so, then the system will freeze up,
giving the BDE error "LOCK TIME OUT". If all users exit the system, the
system will become available again. I have had no table corruption so far.
This has been going on for about 2 weeks. Users are getting upset as this
is a type of POS system.

The system is Paradox ver 9 Runtime on all Win XP operating system clients.

Any and all suggestions are welcome. Management will soon be forcing me to
re-write application as this is unacceptable to them. The app has been
running for 10 years.
Please email me or post on the newsgroup.

Oscar...

Take off (uncheck) 'let OS put to sleep to conserve energy' on *all* network
cards.

Uncheck 'write cache' on at least the server.



When you say clustered, you do mean with one system acting as a server -
correct?


--

Tony McGuire
"It's not about having enough time. It's about priorities."
___________________________

How about the workstations? I assume the have the BDE installed locally so
then the LOCAL SHARE should be set to TRUE on each workstation.

If you are experiencing problems, change the oplocks setting also on the ws.


Anders

Missed that.

Why do the servers even have Paradox/BDE installed?


--

Tony McGuire
"It's not about having enough time. It's about priorities."
___________________________

Tony,

The Windows 2003 Server has 2 nodes where both nodes are always ACTIVE.
The server is only doing FILE server duties, ie the F drive of each
workstation is "mapped" to this server. There is only 1 BDE config file in
use for all workstations. Command line has "-o" switch to use this BDE
config file.

Where/How do you "uncheck" the write-cache for the server?

Thanks for your input
Oscar


"Tony McGuire" <png.paradoxcommunity@com> wrote

Anders,

I thought the OPLOCK settings were only for the SERVER?
Do I have to change each workstation also?


"Anders Jonsson" <gt3TakeThisAway (AT) bredband (DOT) net> wrote

Tony,

The server does NOT have the BDE installed, just the IDAPI32.CFG file is on
the server. That way all workstations use the same file.

"Tony McGuire" <png.paradoxcommunity@com> wrote

In my opinion changing it on the server *should* be enough but the common
advice among Paradox developers is to change it also on ws.

Anders

Oscar Santiesteban wrote:
Opportunistic locking probably has no bearing on this problem.

I suspect that there is a hardware or network problem lurking somewhere.
The system event-log might contain useful entries. A networking contractor
will have the specialized network-testing hardware needed to look for
problems that might otherwise remain hidden.


----
ChimneySweep(R): F-A-A-ST table repair at a click of the mouse!
http://www.sundialservices.com/products/chimneysweep

Oscar Santiesteban wrote:
Hi Oscar

Are we talking about failover clusters or SAN clusters? Is there a load
balancer involved? In a SAN cluster you're never sure which server node
is actually serving the file, but all are touching the same filespace.
Paradox might survive this through the load balancer, I don't know.

Perhaps that's what you're seeing- another node tries to serve the file
and Paradox deadlocks. You could verify this buy running the app with
only one server node of the SAN cluster turned on, but that's an "off
hours" proposition and hard to test.

My primary job is windows admin, and I'm REALLY suprised someone would
let you disable oplocks on a SAN cluster. That's a tremendous
performance hit. And there's no way Paradox could ever take advantage
of that much horsepower. So either the cluster is there for something
else or it's a failover cluster.

In a failover cluster you should never see the second node unless the
first fails. Is there anything in the event log indicating a node
switchover around the time of your deadlock? You probably can't expect
Paradox to fail over gracefully. There will always be a lag in the disk
mirroring of the second server. You'll probably have to restart the app
on the workstations if that's the problem.

If it's a SAN cluster, I would create a virtual server on one node and
isolate Paradox from the rest of the cluster. VMWare Server (formerly
VMWare GSX) is free now, so that's the way to go unless your servers
have more than two processors. VMWare full locks it's files (except raw
partitions) so Oplocks can run on the host and not on the VM.

HTH

Foster Glascock