VFP CDX Corruption (vfp6)

[boanrb]

Dear friends,

I have a bad situation at hand and it’s as follows:

I help support a Vfp6 app in a hospital and the .dbfs/cdx/fpts are stored on a 64bit Windows Server 2008. They do not use DBC. It’s a mix of OSes; winxp and win7 mostly.

From 2012 October things have been fairly ok. (There has been one problem though. Sometimes vfp fails to save some records posted at client computers without an error)

In March 2014 the app all over sudden started having SEVERE CDX CORRUPTION. The experience is now a nightmare to all.

Recreating the index tags stops the problem for some few hours then cdxes get corrupted again.

Fatal Error exception C000000FD
(The error is at insert level, particulary when a key field is changed)

I googled some info and got a list of things to check for.

1.) Bad characters in fields {I removed especially from key fields but the problem persist}
2.) Disable Oplocks {IT manager refused siting –ve implications on some applications}
3.) One bad NIC could result in bad behaviour – {not able to test this]
4.) Bad network environment – {not sure what to look for}
5.) Disable SMB2 – {not sure of any -ve implications on the network}

The system is actually unusable for now.

Kindly advise on what to do.

Benson

 

[Olaf Doschke]

You found some good advice. That's only solvable by 2) and that needs 5) as prerequisite.

What we did at a company was introducing a separate "slow" fileserver for DBFs with SMB1 and no oplocks (it's running 2003, but you could also run 2008 with SMB2 disabled and oplocks disabled).
Move data there and it'll not break as often as with oplocks.

Bye, Olaf.

 

[craigber]

There are many things that can cause CDX corruption.

- The design of the software. All data should be buffered, never edited directly
- Bad hardware. This could be anything from a bad network connector to a failing router or hub. Even wiring can go bad. If network cabling runs parallel to power cables, it can cause a problem
- Poor wireless connections. If a network connection goes up and down, it can be a problem
- Mobile/portable devices. If a doctor or nurse walks around with a mobile device and the device switches wireless access points while they're in the middle of an edit.


Bottom line, it may be worth swapping out DBFs for a SQL backend.


Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

it may be worth swapping out DBFs for a SQL backend.

That's always a good approach, and has many advantages.

But keep in mind that it won't be trivial. It's not like moving your DBFs to a different server. Depending on how your application is structured, you could face a lot of re-coding, and there will be many important issues to deal with (such as different data types, differences in SQL syntax, etc).

I'm not saying don't do it. But you should ideally do it when you have plenty of time for coding and testing, not under the pressure of your present emergency situation.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[boanrb]

Olaf ,

Thanks for you valuable input. Sorry for the time zone differences; I have just seen this now and I will try the advise out.

Should this (SMB2 change) be on the server or the workstations?

Mike,

Thanks for your input. SQL is the best solution but as you say under current emergency situation.

I appreciate your input friends.

Benson

 

[Olaf Doschke]

Both the SMB2 and oplocks only work, if both clients and server agree. If one side doesn't offer something it can't be done. Think about the situation we have: One additional server for the DBFs doesn't make sense, if you turn off SMB2 and oplocks at the clients, because then you could also do without a secondary server.

So whatever software can profit of oplocks does, but DBF access doesn't use them. The outcome is stability, but it's slower. Doesn't mean, that it's awfully slow, anyway.

To illustrate the stability gain: Like you experience now we had rather daily CDX corruptions and without oplocks it's the occasional maybe once or twice a year, less cdx, more the typical reccount header problem. It's really a major difference.

We do nightly PACKs and REINDEX, rather by using DELETE TAG ALL and rebuilding the indexes from meta data info about index expressions and types. That's done on file copies, so if anything fails during that maintenance there is no copying back of the packed data and at least the previous day state is kept. The problem may then not be in the data, but in resource problems of the server(s) used (cpu/ram), during the nightly run. I think this packing and rewriting indexes makes them more stable also and performant anyway, you really see indexes wearing out, if they get unbalanced in the binary tree branches, which a newly created index does not have.

Bye, Olaf.

 

[boanrb]

Olaf,

Thanks for your concise advise. We are making the changes on both the server and the client machines and will post here to let you know how things will go.

Your advise is much appreciated.

Benson

 

[Olaf Doschke]

>We are making the changes on both the server and the client machines
OK, so you're not going for a secondary server and only turn off oplocks there?
Well, you'll see how that affects everything else, too, and then can decide whether to add a server or not.

Bye, Olaf.

 

[boanrb]

Olaf,

I am told by the IT manager that the server is primarily for the vfp app and nothing else so I guess there is no problem?

Thanks once again.

Benson

 

[Olaf Doschke]

Oh, if that's the case, then no other application needing any other file types would be effected, yes.

Bye, Olaf.

 

[GriffMG]

This does sound like an op locks problem.

Losing SMB2 will most likely resolve the problem, as this will enable you to be rid of the op locks.

Op locks was introduced by M$ purely to make it's networking seem faster in the popular magazine network
performance tests of the 80s - it does nothing useful in real life and won't slow down you network measurably
if you drop it - the original target was to try and match Novel's Netware performance, by 'pretending' to share
small files when they were really opened exclusively and copied down to a workstation and processed locally.

M$ seems to have retained oplocks because it can help in their push for people to move away from local Access
databases and VFP like systems... all just my penny worth,

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[boanrb]

Thanks all. Thanks alot!

 

[GriffMG]

One way to avoid op locks - which I have found works rather well, where I can't get a client to
disable them - is to open the files in shared mode on the server before any workstation can get to them.

If the server has the files open it cannot provide op locking, so everyone has to work as they should.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[boanrb]

Griff,

I have been having the thought to try your suggestion but I have not come accross some info on the pros and the cons.

Will data corruption be avoided in this case? If the data is first opened on the server as you suggest? I want to try that, seriously. Do you have any info on what happens behind the scenes in such cases?

Benson

 

[GriffMG]

Hi

If you can get a simple vfp program to ope the files in shared mode - using an executable running on the server
then when a workstation goes to open the file it cannot be given it in an exclusive mode - so op locks is simply
defeated.

To make this work you either have to have a service running on the server, or leave it with a logged in session that
runs the executable.

You might make it do something useful while it has the files open - provide reports or something - perhaps do back-ups
during 'down periods'.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[boanrb]

Thanks Griff. That's exactly what I am going to do.

Thanks so much.

Benson

 

[GriffMG]

Good luck

Let us know how you get on.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[boanrb]

I will definitely post back!

 

[Olaf Doschke]

Yes, I can confirm what Griff says, because of the nature of oplocks they only are ever given to a first user until a second user wants access. But if your exe is the only process having access it'll have an oplock.
If the first user is your exe the first real user can't get an oplock, but will break it. Going that route I'd use a table shared twice from a server EXE, so even that process of breaking the oplock has already been done, then. Eg make sure your EXE starts twice to be two processes using the DBFs. The one advantage is, that other apps using other files will continue to get oplocks, the disadvantage obviously is you never will have exclusive access, but you can of course control your own EXEs to close the files, when real exclusive access is needed.

It's obviously easier to have the registry settings. You can get a msi at ALASKA software. See:

http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking

http://www.alaska-software.com/fixes/smb2/overview.shtm#download

Bye, Olaf.

 

[GriffMG]

Olaf, I think a file open from the server itself will not result in an oplock at all, I might be wrong.

The trouble with them is that although the first user will often get an op lock, the second and subsequent ones
can't always break that - M$ made a bit of a hash of the protocol, even in their own products, so sometimes
the first user gets the op lock, then the second and subsequent users cannot open the file at all.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​