Please don't worry about questioning my abilities. I don't know enough about
these things, and in my experience, the computer systems person who says
they know everything, is either lying, or over confident and likely to see a
complete network failure sooner rather than later.
Local Share in the BDE is set to ON for every machine.
I will get each machine checked for the Write Behind setting. Steve
mentioned the OpLocks setting. This is a setting on Novell Client though
Tony asked about UPS & power management.
Yes we have a UPS on the server, and Power Management is shut off in the
BIOS on server (and on clients). As far as I am aware, none of out NIC cards
are set to turn off. We will check these though.
Hardware - this is a possible area of problem, now you mention
Hubs/Switches. We do have a couple of older offices with Hubs, and not
switches. These are the offices that have recently had extra staff in them
using the database.... can you tell me why hubs could be a problem in this
If non of this works, I am going to get the code taken apart and looked at
bit, by bit, though you will all appreciate that this will be the hard and
Thanks everyone, I look forward to your responses.
> Just double checking - LOCAL SHARE is a BDE setting, nothing to do
> with NetWare, should be the same on each client machine.
> Write-behind caching is not a NetWare thing, it's a Windows thing. On
> Win2K/XP you can find it in the properties for the drive, hardware
> tab, select drive, click properties button, select disc properties
> tab, uncheck "Write cache enabled" box if possible. Only matters for
> local HDDs on a Windows computer. NOTE: I cannot get this to stick -
> reboot and the box is checked again. I've never seen anyone else
> report differently or how to fix it, so my suggestion is to not put
> any shared .DB files on a Windows machine.
> Win9x: Control Panel, System applet, Performance tab, File System
> button, Troubleshooting tab, CHECK the boxes labeled:
> i. "Disable new file sharing and locking semantics."
> ii. "Disable write-behind caching for all drives."
> iii. On the Hard Disk tab, you may wish to try setting Read-ahead
> optimization to None, but I think that should only make a difference
> on the server machine.
> If you're 100% certain that 100% of the hardware involved (all RAM
> (esp. server's), all cables, all switches (you are using switches
> rather than hubs, right?), all NICs, all HDDs etc.)*, then I'd say
> it's time to look at user behavior and code. Is a user doing
> something you didn't develop for? Is the code doing things which
> require full table locks (queries, add(), cMax() (any c..() function),
> etc.)? Is the code not trapping all errors? Do you have potential
> terminal loops (I've seen apps prompt the user for input or to select
> a menu item and not let the user out until a valid input was made or
> menu item selected - if a user wants to cancel, there's no way but to
> Ctrl+Alt+Delete, and if a user really wants to cancel, that's what the
> user will do.).
> *A database app will be the first thing to tell you there's hardware
> problems. Unfortunately, the hardware guy will be the last person to
> believe this. I'll let you fight the battle.
> NOTE: I'm not questioning your abilities, but like Steve said, these
> things have to be asked because it's not normal for a Paradox DB to
> die on a NetWare network.
> What changed recently (just before the lockups started)? How many
> users do you have?
> > No don't worry about attacking my skills - I'm not trained for this.
> > >what is the server?.. is LOCAL SHARE always TRUE?.. are the oplocks and
> > > write-behind settings disabled everywhere?
> > Compaq Presario, running Novell Netware 4.11
> > Local Share is always true/On.
> > Oplocks disabled on all clients.
> > I can't see a write-behind option (I assume this is a Novell Client
> > > >  Examined lck files after lockup, using netdump and lockdump.
> > > which sessions abort?.. which sessions don't clear from the files?..
> > honest
> > > question - do you really know what you're looking for in those files?
> > No, I don't really know what I'm loking for in these files., but I did
> > the results here, and people explained what was going on. Perhaps
> > could point me in the direction of a guide, and I'll try again.
> > > professional sniffer, or you and/or your own people casually?
> > No, it was done properly, we found a couple of problems, but nothing
> > solved the DB issues.