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]

>a file open from the server itself will not result in an oplock at all
You could be right about this, but it would be inconsequent. Even locally you'd have an advantage in prefetching the file into memory and having a quasi exclusive lock until a secondary file access occurs.

Bye, Olaf.

 

[boanrb]

Hi Friends,

They did everything as advised but the problem persists. I stayed at the hospital the whole night and the few users who on duty did not complain about anything till morning.

They posted transactions and everything was very ok. By the time I was leaving in the morning nothing wrong had transpired.

1.) The SMB2 on the server was disabled and Oplocks as well
2.) The SMB2 on the workstations was disabled as well
3.) Did a reindex from scratch for all tables
4.) I created some routines on the server with the tables open (the app started before anyone else got it)
5.) For the few users at night all was well.

When the day workers reported and started their workstations, the system started showing all the signs related to corrupted indexes:

1.) There is data but the reports wont show them - the app cant 'see' them using the indexes. but a normal browse shows the records

2.) The infamous "Fatal Error exception c000000fd"

Other info: There are around 100 users accessing the app and the NICs I am told are of good speeds; new that is.

From here, I think, I am at seas. I will very much appreciate any help towards resolving this problem.

Benson

 

[GriffMG]

Well, you have certainly knocked out the op locks problem. Although it sounds quite a feat to have killed it
on your circa 100 workstations overnight.

Are your indexes structural - can you be sure they are being opened by anything that might update them?

Do they have particularly long keys, or likely to have a very large number of identical keys?

Is there perhaps a patch of spoilt records in one of the tables - that might cause an index crash?

Are they only updated by the app, or could someone be using another means of access - such as ODBC or
from an M$ Access app?

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. ​

 

[Olaf Doschke]

Computers have to restart to let registry changes be effective. Did you do that?
Did you apply the MSI from Alaska soft or what changes did you apply?

Bye, Olaf.

 

[boanrb]

Griff,

The IT manager has a team of staff who helped her.
>> structural indexes
Yes the app is using CDXes all through.
>> particularly long keys & large number of indentical keys
Not quite but to be honest I don't know how long this would need to be to cause issues
>>spoilt records
I removed bad characters. Kindly let me know how to tell a bad record.
>> updates from another app
there isn't as far as I know

Thanks Griff

Benson

 

[boanrb]

Olaf,

Yes they did a restart on the workstations.

msi: No. The registry was edited manually.

Thanks for your input.

Benson

 

[GriffMG]

Well, if a table gets spoilt then browsing it will often show the corrupted bit
as either blank records or fields or offset data - or sometimes as non printable characters

Do you have a means to browse the tables in native VFP?

If not you could use this:

http://www.finedata.com/support/browser.zip

(You might need VFP9 runtime support)

http://www.finedata.com/shdata/vfp9sp1supportrefresh.exe

Most errors in programming happen at the boundaries of things, like passing the extreme
of an array or using a really long URL to break through the security on a web site.

So, a long index key is likely to be approaching 240 characters in a CDX
I have an app where the key is about 230 chars and this does cause it to crash periodically.

With any index there is a limit to the number of identical keys before it can become unstable
(something to do with updating binary trees I think), so where this has happened to me in the past
I have added a redundant field to the end of the index key, str(recno(),12,0) for example, which then
ensures the index key is always unique. This is very much a long shot though.

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,

Yes. I use the normal vfp command window to browse the records. The bad characters I noticed I wrote some code to clear them from the fields.

Thanks

Benson

 

[Olaf Doschke]

>Yes they did a restart on the workstations.
And the server? It's much more important

>msi: No. The registry was edited manually.
So what changes did you do exactly? You find several different instructions on what to do and where. Sometimes a key to change is missing, then you have to create it, that's often seen as nothing to do instead, which is wrong.

Bye, Olaf.

 

[boanrb]

Olaf,

The server was restarted yes. The key to change was missing so we added the same as per instructions.

Thanks

Benson

 

[Olaf Doschke]

>The key to change was missing so we added the same as per instructions.
OK, sounds good. Still, what keys did you add and change. Can you simply point me to the instructions used? As I said there are several and some are incomplete.
The ALASKA MSI really is a simple way to apply all changes needed.

Bye, Olaf.

 

[boanrb]

Olaf,

Sorry. It's here:

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

Thanks

 

[Olaf Doschke]

Ok, that's a good resource, yet not very precise on what exact registry key type to add. Did you create DWORD registry keys SMB2 and SMB1 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters?

Bye, Olaf.

 

[boanrb]

Olaf,

No. SMB2 only. I guess this was not okay?

Thanks for your input.

 

[Olaf Doschke]

Once SMB2 and SMB3 are disabled, SMB1 should be re-enabled to be used again and the methods described above applied to disable oplocks for SMB1.

You have to Disable SMB2 *and* enable SMB1. And these two steps are still just enabling you to turn oplocks off. You also have set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters EnableOplocks = 0, I hope.

Bye, Olaf.

 

[boanrb]

Olaf,

I think I missed that - enabling SMB1. Is it too late to use the ALASKA MSI now, you think?

If I add the SMB1 will that suffice?
Do I need to do it in all workstations afresh?

Thanks for you patience.

Benson

 

[Olaf Doschke]

Dataaccess clearly says what to do at clients and at servers and at both.

Actually again learn from my situation: We did nothing at any client and just used an older server OS not capable to offer SMB2 or oplocks. So the server is the main computer to care for. We did nothing at any client or server for that reason. It's obviously much easier.

Looking in detail at the alaska site, the msi they offer is for clients only ("This MSI package needs to be executed on any Vista and Windows 7 workstation") workstation=client, not server. It cares for other parameters in HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\LanmanWorkstation\Parameters.

Again, oplocks are a feature requested by systems having it configured and fulfilled by servers offering it. If one side doesn't request or offer oplocks, they are not made.

So concentrate on the server. It's important your keys are the right type DWORD for them SMB2 and SMB1 keys. Also for the EnableOplocks=0 key, see

http://support.microsoft.com/kb/296264/en-us.

Don't forget more modern servers even offer SMB3. Windows Server 2008 doesn't offer SMB3, AFAIK, but 2008R2 perhaps. 2008R2 is not just a service pack of 2008, it's a major version higher, so verify what you have at hand, there.

Bye, Olaf.

 

[Olaf Doschke]

Just as a side note: VFP6 was also not a very stable VFP version in itself. VFP7 dbfs even had worse bloat effects on FPTs. You could also get more stable recompiling in VFP9 and moving data into tables created by VFP9 without changing anything else.

Bye, Olaf.

 

[boanrb]

Olaf,

I appreciate your input. I will consider your suggestions

Thanks a lot.

Benson

 

[boanrb]

Hi,

The IT manager made the registry entries as Smb1 and Smb2. From Microsoft I have SMB1 and SMB2. Are these keys case-sensitive?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB1
REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled

To enable or disable SMBv2 on the SMB server, configure the following registry key:
Registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB2
REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled