Corrupted Paradox DBs

[Bob Berry]

D7, Win2K

Many moons ago I asked a question in this group re occasional instances of a
Paradox DB getting corrupted. I got an answer that seemed to work, but I
cannot find where I filed it away. I have an ancient customer who is still
on Paradox/BDE who is having the problem. I believe I was told to set the
BDE Init Definition "Local Share" to True to alleviate the problem. Can
someone verify that this might be a solution?

[Tony McGuire]

Post by Bob Berry
BDE Init Definition "Local Share" to True to alleviate the problem. Can
someone verify that this might be a solution?

Might do it, yes.

[Bob Berry]

Tony,

Thanxabunsch!

Bob

Post by Tony McGuire

Post by Bob Berry
BDE Init Definition "Local Share" to True to alleviate the problem. Can
someone verify that this might be a solution?

Might do it, yes.
--
-----------------------------------
Tony McGuire

[Steven Green]

I believe I was told to set the BDE Init Definition "Local Share" to True to
alleviate the problem. Can someone verify that this might be a solution?

"might be" is correct.. correct settings for Local Share, Oplocks, and Caching
should greatly reduce the chances of corruption.. but there's also failing
hardware, unstable power, lockups and crashes, users re-booting, etc..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Bob Berry]

This is a desktop application. Single user, no server. How important are
Oplocks and Caching in this environment?

Post by Steven Green

I believe I was told to set the BDE Init Definition "Local Share" to True to
alleviate the problem. Can someone verify that this might be a solution?

"might be" is correct.. correct settings for Local Share, Oplocks, and Caching
should greatly reduce the chances of corruption.. but there's also failing
hardware, unstable power, lockups and crashes, users re-booting, etc..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Bill Todd]

Opportunistic locking is not important but write caching is still an
invitation to corrupt tables if the computer or application crashes.

[Steven Green]

Post by Bill Todd
Opportunistic locking is not important but write caching is still an
invitation to corrupt tables if the computer or application crashes.

oplocks *is* an issue, in that it will give you the "table and index"
error if it is not disabled.. this isn't true "corruption", but it *is*
99% of all "my tables are damaged" complaints..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Peter Stromblad]

Hello All,
I've been following items of corruption for a long time now, once I thought
I had the answer but then yikes...

This will be a rather lengthy elaboration - so bear with me please:

At a customer site we developed in 92-97 a production planning system, which
then ran on different clients connected to various NW-servers. The BDE apps
(written in delphi and Paradox) ran without any corruption, index failures
for years. One of the apps hasn't been modified since 95, the others since
97. Up until 2001 neither had a crash, then once a year to last years crash
every week, with data-loss, index corruption, validity checks going invalid,
reference links broken etc.

What has changed then, well - they've gone from Novell NW to Windows Server
2000 in 2001, then 2003, we upped the servers to 2003. Clients have been
mixed since 2001 consisting of 95/98/NT4/W2K, until last year when the old
clients was changed to XP Pro and a W2K3 Terminal Server, but one computer
which is a Win98SE, running the legacy paradox app. There is a server farm
of 5 servers all having W2K3SP1.

Another accounting system was run as well, based on MS-Access tables. This
software had frequent crashes of the DB, resulting in leaving Access and
going to SQL-Server - now with no crasches.

OpLocks has always been disabled on the server holding the file-share, but
not on the others. I'll dwell into this a little later.

In repairing the production planning system this time, I'm taking more time
to all the details. So here comes the elaborative thinking which I
desperately need help with:

I excluded all users and ran the app from the terminal server, load tested,
did an odbc-connection and stressed the db. Then with one query, a simple
but big join the system hung. Upon repeated connection tries I couldn't get
the BDE to initialize - simply because the .NET file and the .LCK files
where locked (BDE reported $2A04). Then I investigated the local files, and
found temporary copies of the .LCK files. I beleived I had disabled all
local caching by denying the oplocks from the server, apparently not. The
legacy 16-bit Paradox-app apparently locked me out in conjunction with file
caching. In the stress test I only did reads, not any writes (deliberately)
so the system was unaffected. The only files then working on the share must
have been the two LCK files and the NET file.

Conclusion is that the JET problem we had (accounting system with access db)
and the PDX problem we now have are related, and they must be related to the
change of client speed and in combination with upgrading firstly from Novell
to W2K but especially in upgrading to W2K3 Server.

First of all: Do all clients (W98/W2K/WXP/W2K3TS) obey the oplocks setting
from the server?
(I read somewhere that W2K totally disregards this setting)
Or- do all clients mrxsmb/parameters/OpLocksDisabled need to be set?
ans so - in conjunction with
LanmanWorkStation/parameters/UseOpportunisticLocking =0 ?

Why do I get local temp copies of the LCK files, and how do I Not get them?
Is the cscEnabled flag involved in this?
Below is a mentioning of write caching, should this be disabled and if so
how?

Any hints are welcome,
the obvious that don't need to be answered:
LOCAL SHARE is True,
the BDE is 5.11
SymAvir is set not to scan (DB,LCK,LDB,MB,MDB,PX,TMP,VAL,X??,Y??,REM and
network drives)
The apps have been flawless for years but the OS and HW has changed, HW is
unlikely the fault, OS-settings probably the fault in my opinion. And yes, a
move to a "real" db-server ... is another issue.
My BDE is a bit rusty so I apologize.

Cheers / Peter S. / WorkOrder AB / Sweden

Post by Steven Green

Post by Bill Todd
Opportunistic locking is not important but write caching is still an
invitation to corrupt tables if the computer or application crashes.

oplocks *is* an issue, in that it will give you the "table and index"
error if it is not disabled.. this isn't true "corruption", but it *is*
99% of all "my tables are damaged" complaints..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Steven Green]

Post by Peter Stromblad
First of all: Do all clients (W98/W2K/WXP/W2K3TS) obey the oplocks setting
from the server? Or- do all clients mrxsmb/parameters/OpLocksDisabled need to
be set?

oplocks nust be disabled on *every* machine

Post by Peter Stromblad
Why do I get local temp copies of the LCK files, and how do I Not get them?

normal reason is the private directory is on a local drive, but local access can
be involved in any number of ways

Post by Peter Stromblad
Below is a mentioning of write caching, should this be disabled and if so how?

caching must be disabled on *every* machine

Post by Peter Stromblad
LOCAL SHARE is True,

local share *must* be true on every machine..

and if old PdoxDOS is running on local machines, it *must* be configured as a
"sharable" copy, not a "standalone" copy right out of the box..

none of this is an iron-clad guarantee.. but collectively is comes real close,
as long as failing hardware, unstable power, and stupid users aren't factors..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Peter Stromblad]

Post by Steven Green

Post by Peter Stromblad
Below is a mentioning of write caching, should this be disabled and if so how?

caching must be disabled on *every* machine

Steven pls - how?

/Peter

[Steven Green]

Post by Peter Stromblad

Post by Steven Green
caching must be disabled on *every* machine

Steven pls - how?

on 95/98/ME, the checkboxes.. no-brainer.. on old NT boxes, there was a registry
entry that's been documented, but I don't have it in front of me..

on the new 2000/XP/2003 machines, I haven't been able to find an intelligent MS
KB article with a valid registry entry to use (see my URL Links page for the
other stuff).. all I can offer is to go to the properties of the drive itself
and do it there.. a real PITA if you have a lot of machines..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Peter Stromblad]

Aha, I beleive you're talking about write behind cache et al, in the
adapters / drives - yes thats different than software cache of the os and
differs with IDE / scsi/ sata / raid etc. - right?

Post by Steven Green

Post by Peter Stromblad

Post by Steven Green
caching must be disabled on *every* machine

Steven pls - how?

on 95/98/ME, the checkboxes.. no-brainer.. on old NT boxes, there was a registry
entry that's been documented, but I don't have it in front of me..
on the new 2000/XP/2003 machines, I haven't been able to find an intelligent MS
KB article with a valid registry entry to use (see my URL Links page for the
other stuff).. all I can offer is to go to the properties of the drive itself
and do it there.. a real PITA if you have a lot of machines..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Steven Green]

Post by Peter Stromblad
Aha, I beleive you're talking about write behind cache et al, in the
adapters / drives - yes thats different than software cache of the os and
differs with IDE / scsi/ sata / raid etc. - right?

correct..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[*Lysander*]

In article <***@diamondsg.com>, ***@diamondsg.com
says...

Post by Steven Green
local share *must* be true on every machine..

Steven,
is there a reliable source for this? Any technical paper maybe?
I always had LOCALSHARE = false back in Netware times and never any
problems.

So far all I've heard was rumours about data-corruption when setting
LOCALSHARE=false on Windows-Servers. But those rumours were scary enough
for me to not even try setting it back to false.

On the other hand, there are a lot of people claiming that
LocalShare=TRUE only is necessary in P2P-networks, not with a real
server... again... only rumours, no facts at all.

If you have anything more solid, I would be very thankful if you could
lead me to the technical resources.

[Steven Green]

Post by *Lysander*
is there a reliable source for this? Any technical paper maybe?
I always had LOCALSHARE = false back in Netware times and never any
problems.

setting it to TRUE forces the BDE to flush all internal buffers to disk..
even on a standalone machine.. just like all the other related concepts
(oplocks, etc) you want to avoid any attempt, at any level, to cache your
data files.. paradox tables are actually a collection of files that *must*
be written to disk together..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Bill Todd]

Post by *Lysander*
says...

local share must be true on every machine..

Steven,
is there a reliable source for this? Any technical paper maybe?

Yes, there is. See
http://community.borland.com/article/0,1410,15247,00.html

Post by *Lysander*
I always had LOCALSHARE = false back in Netware times and never any
problems.

That is correct. On a NetWare network the BDE can reliably determine
that the database is on a shared drive so it sets local share for you.

Post by *Lysander*
So far all I've heard was rumours about data-corruption when setting
LOCALSHARE=false on Windows-Servers. But those rumours were scary
enough for me to not even try setting it back to false.

The real problem with a Windows network comes when the server is also
used as a workstation. The instance of the BDE that is running on a
non-dedicated server cannot tell that the database is being shared and
will, therefore, attempt to cache writes to improve performance. This
is, of course, a recipe for disaster if the database is being shared.

Post by *Lysander*
On the other hand, there are a lot of people claiming that
LocalShare=TRUE only is necessary in P2P-networks, not with a real
server... again... only rumours, no facts at all.

All Windows networks are peer-to-peer regardless of whether the network
has one server or 100 servers. In a single user application the BDE
will also cache writes and this is also very risky if Windows crashes
since all of the unwritten data in the write cache will be lost.

[*Lysander*]

Post by Bill Todd
Yes, there is. See
http://community.borland.com/article/0,1410,15247,00.html

Thanks, Bill.
But still there is no definite answer on what to do if I have dedicated
servers.

I would not use my server as workstation, and would not install a BDE on
it. Is it safe, then, to set LOCALSHARE = false?

Because I was doing tests and LOCALSHARE=false is MUCH faster in
accessing the rest of my old dBase-tables.

[Bill Todd]

Post by *Lysander*

Post by Bill Todd
Yes, there is. See
http://community.borland.com/article/0,1410,15247,00.html

Thanks, Bill.
But still there is no definite answer on what to do if I have
dedicated servers.

Yes there is. The article says, "This must be done on all BDE clients
that
access the tables on networks listed above. This is not
necessary for Novell File Server type networks." and Windows NT is in
the list.

Post by *Lysander*
I would not use my server as workstation, and would not install a BDE
on it. Is it safe, then, to set LOCALSHARE = false?

As I said earlier, it is not the number of machines that are being used
as servers that determine whether a network is peer-to-peer. It is
whether the network architecture allows it to be peer-to-peer. Windows
networks are always peer-to-peer regardless of the number of servers
and regardless of whether the servers are dedicated.

Post by *Lysander*
Because I was doing tests and LOCALSHARE=false is MUCH faster in
accessing the rest of my old dBase-tables.

That is because no locking is performed and write caching is used, both
of which are unsafe in a multi-user environment.

[*Lysander*]

Post by Peter Stromblad
Windows
networks are always peer-to-peer regardless of the number of servers
and regardless of whether the servers are dedicated.

Thanks, Bill.
This view on the things make the Borland article very clear, of course.

Post by Peter Stromblad
That is because no locking is performed and write caching is used, both
of which are unsafe in a multi-user environment.

thanks for the explanation; I already figured something like this.

BDE is on it's way out of my application anyway, so I hope that I don't
have problems for the remaining time.

[Peter Stromblad]

This is an update to the below:
We'll do the following tonite,
Update all clients and servers registry with the following values:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MRxSmb\Parameters]
"CscEnabled"=dword:00000000
"OpLocksDisabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanworkstation\parameters]
"UseOpportunisticLocking"=dword:00000000
"UtilizeNtCaching"=dword:00000000
"UseUnlockBehind"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanserver\parameters]
"EnableOpLocks"=dword:00000000

Then update BDE to 5.2
Change the Net Dir to a UNC path
Re-Verify LOCAL SHARE=TRUE
Re-Verify all antivirus installations that they indeed exclude all
extensions mentioned below
Re-Verify all validity checks, and rebuild all tables
Delete all LCK and NET presence
Restart all 30 Clients.
Test

I'll update the list as to how it went, after the users again are let in on
it.

Cheers / Peter S. / WorkOrder AB / Sweden

Post by Peter Stromblad
Hello All,
I've been following items of corruption for a long time now, once I
thought I had the answer but then yikes...
At a customer site we developed in 92-97 a production planning system,
which then ran on different clients connected to various NW-servers. The
BDE apps (written in delphi and Paradox) ran without any corruption, index
failures for years. One of the apps hasn't been modified since 95, the
others since 97. Up until 2001 neither had a crash, then once a year to
last years crash every week, with data-loss, index corruption, validity
checks going invalid, reference links broken etc.
What has changed then, well - they've gone from Novell NW to Windows
Server 2000 in 2001, then 2003, we upped the servers to 2003. Clients have
been mixed since 2001 consisting of 95/98/NT4/W2K, until last year when
the old clients was changed to XP Pro and a W2K3 Terminal Server, but one
computer which is a Win98SE, running the legacy paradox app. There is a
server farm of 5 servers all having W2K3SP1.
Another accounting system was run as well, based on MS-Access tables. This
software had frequent crashes of the DB, resulting in leaving Access and
going to SQL-Server - now with no crasches.
OpLocks has always been disabled on the server holding the file-share, but
not on the others. I'll dwell into this a little later.
In repairing the production planning system this time, I'm taking more
time to all the details. So here comes the elaborative thinking which I
I excluded all users and ran the app from the terminal server, load
tested, did an odbc-connection and stressed the db. Then with one query, a
simple but big join the system hung. Upon repeated connection tries I
couldn't get the BDE to initialize - simply because the .NET file and the
.LCK files where locked (BDE reported $2A04). Then I investigated the
local files, and found temporary copies of the .LCK files. I beleived I
had disabled all local caching by denying the oplocks from the server,
apparently not. The legacy 16-bit Paradox-app apparently locked me out in
conjunction with file caching. In the stress test I only did reads, not
any writes (deliberately) so the system was unaffected. The only files
then working on the share must have been the two LCK files and the NET
file.
Conclusion is that the JET problem we had (accounting system with access
db) and the PDX problem we now have are related, and they must be related
to the change of client speed and in combination with upgrading firstly
from Novell to W2K but especially in upgrading to W2K3 Server.
First of all: Do all clients (W98/W2K/WXP/W2K3TS) obey the oplocks setting
from the server?
(I read somewhere that W2K totally disregards this setting)
Or- do all clients mrxsmb/parameters/OpLocksDisabled need to be set?
ans so - in conjunction with
LanmanWorkStation/parameters/UseOpportunisticLocking =0 ?
Why do I get local temp copies of the LCK files, and how do I Not get them?
Is the cscEnabled flag involved in this?
Below is a mentioning of write caching, should this be disabled and if so
how?
Any hints are welcome,
LOCAL SHARE is True,
the BDE is 5.11
SymAvir is set not to scan (DB,LCK,LDB,MB,MDB,PX,TMP,VAL,X??,Y??,REM and
network drives)
The apps have been flawless for years but the OS and HW has changed, HW is
unlikely the fault, OS-settings probably the fault in my opinion. And yes,
a move to a "real" db-server ... is another issue.
My BDE is a bit rusty so I apologize.
Cheers / Peter S. / WorkOrder AB / Sweden

Post by Steven Green

Post by Bill Todd
Opportunistic locking is not important but write caching is still an
invitation to corrupt tables if the computer or application crashes.

oplocks *is* an issue, in that it will give you the "table and index"
error if it is not disabled.. this isn't true "corruption", but it *is*
99% of all "my tables are damaged" complaints..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Steven Green]

Post by Peter Stromblad
Re-Verify all validity checks, and rebuild all tables
Delete all LCK and NET presence

you can use Remlok32, on my web site, to help delete all the net and lock files
easily..

also, it helps to pack the tables and indexes (restruct) after a rebuild..

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Tony McGuire]

Post by Steven Green
you can use Remlok32, on my web site, to help delete all the net and lock files

Something I've been meaning to ask...

If 'Show hidden and system files' is UNchecked, and the .lck/.net files aren't
visible in Windows Exploder, will Remlok32 still find them?


--
-----------------------------------
Tony McGuire

[Steven Green]

Post by Tony McGuire
If 'Show hidden and system files' is UNchecked, and the .lck/.net files aren't
visible in Windows Exploder, will Remlok32 still find them?

yes.. remlok doesn't use explorer to find the files (g)


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Peter Stromblad]

Here is another update on this issue, just for reference.

It's now been a month since we did undertake the below changes, and the
result...
Yes, it works again. Not one crash, not one corrupted index, not one
destroyed relation, not one destroyed integrity setting.
For you who have not followed this, the below stated problem exists with all
file based databases on Windows networking, We've searched and researched
foxpro, access, dbase, paradox and even shared instances of excel-sheets.
You have to disable oplocks on all clients and servers and disable write
caching on the server-drives if they're not a proper RAID set.

Best regards / Peter Stromblad / WorkOrder AB - Sweden

Post by Peter Stromblad
We'll do the following tonite,
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MRxSmb\Parameters]
"CscEnabled"=dword:00000000
"OpLocksDisabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanworkstation\parameters]
"UseOpportunisticLocking"=dword:00000000
"UtilizeNtCaching"=dword:00000000
"UseUnlockBehind"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanserver\parameters]
"EnableOpLocks"=dword:00000000
Then update BDE to 5.2
Change the Net Dir to a UNC path
Re-Verify LOCAL SHARE=TRUE
Re-Verify all antivirus installations that they indeed exclude all
extensions mentioned below
Re-Verify all validity checks, and rebuild all tables
Delete all LCK and NET presence
Restart all 30 Clients.
Test
I'll update the list as to how it went, after the users again are let in
on it.
Cheers / Peter S. / WorkOrder AB / Sweden

Post by Peter Stromblad
Hello All,
I've been following items of corruption for a long time now, once I
thought I had the answer but then yikes...
At a customer site we developed in 92-97 a production planning system,
which then ran on different clients connected to various NW-servers. The
BDE apps (written in delphi and Paradox) ran without any corruption,
index failures for years. One of the apps hasn't been modified since 95,
the others since 97. Up until 2001 neither had a crash, then once a year
to last years crash every week, with data-loss, index corruption,
validity checks going invalid, reference links broken etc.
What has changed then, well - they've gone from Novell NW to Windows
Server 2000 in 2001, then 2003, we upped the servers to 2003. Clients
have been mixed since 2001 consisting of 95/98/NT4/W2K, until last year
when the old clients was changed to XP Pro and a W2K3 Terminal Server,
but one computer which is a Win98SE, running the legacy paradox app.
There is a server farm of 5 servers all having W2K3SP1.
Another accounting system was run as well, based on MS-Access tables.
This software had frequent crashes of the DB, resulting in leaving Access
and going to SQL-Server - now with no crasches.
OpLocks has always been disabled on the server holding the file-share,
but not on the others. I'll dwell into this a little later.
In repairing the production planning system this time, I'm taking more
time to all the details. So here comes the elaborative thinking which I
I excluded all users and ran the app from the terminal server, load
tested, did an odbc-connection and stressed the db. Then with one query,
a simple but big join the system hung. Upon repeated connection tries I
couldn't get the BDE to initialize - simply because the .NET file and the
.LCK files where locked (BDE reported $2A04). Then I investigated the
local files, and found temporary copies of the .LCK files. I beleived I
had disabled all local caching by denying the oplocks from the server,
apparently not. The legacy 16-bit Paradox-app apparently locked me out in
conjunction with file caching. In the stress test I only did reads, not
any writes (deliberately) so the system was unaffected. The only files
then working on the share must have been the two LCK files and the NET
file.
Conclusion is that the JET problem we had (accounting system with access
db) and the PDX problem we now have are related, and they must be related
to the change of client speed and in combination with upgrading firstly
from Novell to W2K but especially in upgrading to W2K3 Server.
First of all: Do all clients (W98/W2K/WXP/W2K3TS) obey the oplocks
setting from the server?
(I read somewhere that W2K totally disregards this setting)
Or- do all clients mrxsmb/parameters/OpLocksDisabled need to be set?
ans so - in conjunction with
LanmanWorkStation/parameters/UseOpportunisticLocking =0 ?
Why do I get local temp copies of the LCK files, and how do I Not get them?
Is the cscEnabled flag involved in this?
Below is a mentioning of write caching, should this be disabled and if so
how?
Any hints are welcome,
LOCAL SHARE is True,
the BDE is 5.11
SymAvir is set not to scan (DB,LCK,LDB,MB,MDB,PX,TMP,VAL,X??,Y??,REM and
network drives)
The apps have been flawless for years but the OS and HW has changed, HW
is unlikely the fault, OS-settings probably the fault in my opinion. And
yes, a move to a "real" db-server ... is another issue.
My BDE is a bit rusty so I apologize.
Cheers / Peter S. / WorkOrder AB / Sweden

Post by Steven Green

Post by Bill Todd
Opportunistic locking is not important but write caching is still an
invitation to corrupt tables if the computer or application crashes.

oplocks *is* an issue, in that it will give you the "table and index"
error if it is not disabled.. this isn't true "corruption", but it *is*
99% of all "my tables are damaged" complaints..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------

[Michael Kennedy]

Hello, Peter,

Many thanks for the feedback.

Post by Peter Stromblad
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MRxSmb\Parameters]
"CscEnabled"=dword:00000000

1. I have an OpLocks REG file for automatic setting of all these
parameters, in all Windows OSes. I have "CscEnabled" set to 1 rather than 0.
Are you reasonably sure that a "0" value is correct?

2. "ControlSet001". The key could have "CurrentControlSet", or a value
like the one you quote. I assume a user must check _which_ "ControlSet"s are
in the registry, and make the suggested changes to all sets. (I don't know
how these Control-Sets work anyway - is only one set active, or can
different sets be active in different circumstances).

Best regards,
- Mike

Post by Peter Stromblad
"OpLocksDisabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanworkstation\parameters]
"UseOpportunisticLocking"=dword:00000000
"UtilizeNtCaching"=dword:00000000
"UseUnlockBehind"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\lanmanserver\parameters]
"EnableOpLocks"=dword:00000000
Then update BDE to 5.2
Change the Net Dir to a UNC path
Re-Verify LOCAL SHARE=TRUE
Re-Verify all antivirus installations that they indeed exclude all
extensions mentioned below
Re-Verify all validity checks, and rebuild all tables
Delete all LCK and NET presence
Restart all 30 Clients.
Test
I'll update the list as to how it went, after the users again are let in
on it.
Cheers / Peter S. / WorkOrder AB / Sweden

Post by Peter Stromblad
Hello All,
I've been following items of corruption for a long time now, once I
thought I had the answer but then yikes...
At a customer site we developed in 92-97 a production planning system,
which then ran on different clients connected to various NW-servers. The
BDE apps (written in delphi and Paradox) ran without any corruption,
index failures for years. One of the apps hasn't been modified since 95,
the others since 97. Up until 2001 neither had a crash, then once a year
to last years crash every week, with data-loss, index corruption,
validity checks going invalid, reference links broken etc.
What has changed then, well - they've gone from Novell NW to Windows
Server 2000 in 2001, then 2003, we upped the servers to 2003. Clients
have been mixed since 2001 consisting of 95/98/NT4/W2K, until last year
when the old clients was changed to XP Pro and a W2K3 Terminal Server,
but one computer which is a Win98SE, running the legacy paradox app.
There is a server farm of 5 servers all having W2K3SP1.
Another accounting system was run as well, based on MS-Access tables.
This software had frequent crashes of the DB, resulting in leaving
Access and going to SQL-Server - now with no crasches.
OpLocks has always been disabled on the server holding the file-share,
but not on the others. I'll dwell into this a little later.
In repairing the production planning system this time, I'm taking more
time to all the details. So here comes the elaborative thinking which I
I excluded all users and ran the app from the terminal server, load
tested, did an odbc-connection and stressed the db. Then with one query,
a simple but big join the system hung. Upon repeated connection tries I
couldn't get the BDE to initialize - simply because the .NET file and
the .LCK files where locked (BDE reported $2A04). Then I investigated
the local files, and found temporary copies of the .LCK files. I
beleived I had disabled all local caching by denying the oplocks from
the server, apparently not. The legacy 16-bit Paradox-app apparently
locked me out in conjunction with file caching. In the stress test I
only did reads, not any writes (deliberately) so the system was
unaffected. The only files then working on the share must have been the
two LCK files and the NET file.
Conclusion is that the JET problem we had (accounting system with access
db) and the PDX problem we now have are related, and they must be
related to the change of client speed and in combination with upgrading
firstly from Novell to W2K but especially in upgrading to W2K3 Server.
First of all: Do all clients (W98/W2K/WXP/W2K3TS) obey the oplocks
setting from the server?
(I read somewhere that W2K totally disregards this setting)
Or- do all clients mrxsmb/parameters/OpLocksDisabled need to be set?
ans so - in conjunction with
LanmanWorkStation/parameters/UseOpportunisticLocking =0 ?
Why do I get local temp copies of the LCK files, and how do I Not get them?
Is the cscEnabled flag involved in this?
Below is a mentioning of write caching, should this be disabled and if
so how?
Any hints are welcome,
LOCAL SHARE is True,
the BDE is 5.11
SymAvir is set not to scan (DB,LCK,LDB,MB,MDB,PX,TMP,VAL,X??,Y??,REM and
network drives)
The apps have been flawless for years but the OS and HW has changed, HW
is unlikely the fault, OS-settings probably the fault in my opinion. And
yes, a move to a "real" db-server ... is another issue.
My BDE is a bit rusty so I apologize.
Cheers / Peter S. / WorkOrder AB / Sweden

Post by Steven Green

Post by Bill Todd
Opportunistic locking is not important but write caching is still an
invitation to corrupt tables if the computer or application crashes.

oplocks *is* an issue, in that it will give you the "table and index"
error if it is not disabled.. this isn't true "corruption", but it *is*
99% of all "my tables are damaged" complaints..
--
Steven Green - Waldorf Maryland USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox
---------------------------------------------------
Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Trading Cards and other Sports Memorabilia
---------------------------------------------------