C0000005 after converting from FPW2.6 2

[mescht27]

Hi FoxPerts,

I had an absolute stable application when it was in FPW.
I ran a conversion and did surprisingly few manual adaptions and everything seemed to work fine in VFP9 SP2.
The data stayed having 2.6 headers, since some workstations have to use the old FPW-app.

The error:
The C0000005 occurs every 10-20th time on a CoursorDown in a BROWSE in a BROWSE.

The simplified code:
Essentially it's no more than preparing a menu, READ EVENTS (line 677).
Then the user chooses (in that menu) DO Order.PRG (line 1406).
This consist of:

ON KEY LABEL F9 DO Position.PRG
USE Order
BROWSE && line 298

Position.PRG:

USE ChildList
SET FILTER TO Position.ID_Order = Order.ID_Order
BROWSE && line 83

Then the user moves down the positions-browse with CursorDown.
If the list is longer then the browse window, which then has to scroll --> C0000005
If the user does a DELETE on one position the probability for a C5 is roughly double
- With close to 0%, if there is just one on the network.
- With around 5%, if all 15 users are checking OrderPositions or adding orders (which has C5s as well but much rarer).

The typical VFP9rerr.log entry:
Called from - position line 83 {x:\mghandel\app-vfp\prgs\position.prg position.fxp}
Called from - ON... line 0 { }
Called from - order line 298 {x:\mghandel\app-vfp\prgs\order.prg order.fxp}
Called from - _35n0vnup2 line 1406 {x:\mghandel\app-vfp\mainmenu.mpr x:\mghandel\app-vfp\smghandel.exe}
Called from - ON... line 0 { }
Called from - mainmenu line 677 {x:\mghandel\app-vfp\mainmenu.mpr x:\mghandel\app-vfp\smghandel.exe}

(Sometimes/vague: Eventlog: "application error" 1000 "ntdll.dll")
(Other VFP9rerr.log reveal that all C5 occur on just: SELECT-SQL, READ EVENTS, CLOSE ALL, SELECT, SEEK, REPLACE, GO BOTTOM, IF USED())

What I tried so far:
- RESOURCE=OFF (in config.fpw)
- no HP-printer drivers
- newest graphics drivers in standard mode
- some of the workstations:
- turn of write behind cache
- network card: 100Mb instead of automatically
- deactivate write behind cache
- deactivate write behind cache on server
- rebuilt the CDXs. (not reindexed but deleted and index on ...)
- no virus scanner
- no return in with....endwith
- Delete anything in C:\Documents and Settings\username\Application Data\Microsoft\Visual FoxPro 9.
- Moved all data to another server temporarily
- searched for and deleted all foxuser.dbf
- get rid of SET PATHs that do not exist

Server is W2003, Workstations: XPSP3, W7
VFP: 9.0.0.7432, RunTime (VFP9r): 9.0.0.7423

What can I do? Do you need more information?
I had a similar [blue]thread [/blue] in foxite.com two month ago (Thread ID: 292711). We didn't find the reason or a solution.
My client is doubting my capabilities :-( (which I don't blame her for)

TNX in advance, Martin@Vienna@Austria (@Europe@Earth@Universe)

 

[craigber]

A "C5" error is a Windows error. You've tried a number of things that I would suggest, so time to do something different.

Get rid of BROWSE. It's difficult to use, hard to validate data, and runs directly against the table. It's a leading cause of data corruption because of how it interacts directly with the data.

Replace it with a grid. It should be easy to do. Base the grid's recordsource on a View to avoid corruption issues.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Dan Freeman]

If it works fine in FPW, and some people are still using the FPW app, I'd leave it in FPW.

If you're going to move it to VFP, you should take the opportunity to reengineer using the new tools available. For example, SET FILTER was never a "best practice" and it's even less so since the introduction of parameterized views. That and (as Craig said) replace BROWSE with grids and you'll have a better behaved application with fewer lines of code.

I'll say the obvious: fewer lines of code mean fewer lines of code to debug, support, maintain, and troubleshoot. ;-)

 

[Mike Lewis]

One other thing you should probably do:

Instad of this (in Position.PRG):

USE ChildList

Do this:

IF NOT USED("ChildList")
  USE ChildList IN 0
ENFIF
SELECT Childlist

This has got nothing to do with your problem, but it will lead to better performance (no need to open the table every time they press F9).

Also, if you are going to take Craig's and Dan's advice to do some re-engineering, you should replace the ON KEY LABEL with code in a grid's Keypress event.

The point is that if you get rid of your old-style FPW code and replace it with up-to-date VFP stuff, it's much less likely to crash with C5 errors, and easier for people here to give you advice.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[SnyAc]

Another major source of C00005 errors are corrupted memo fields... I have made a practice of removing memo fields from my table designs wherever possible to avoid the fatal error syndrome.

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[Mike Lewis]

I have made a practice of removing memo fields from my table designs wherever possible to avoid the fatal error syndrome

Hmm. That seems a bit draconian. Wouldn't it be better to figure out why your memo fields are getting corrupted? In my opinion, memo fields are too useful to lose.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[mescht27]

Thanks to all. I am glad.

@Craig: Wonderful idea. I never thought of that, since my picture of BROWSE was a grid anyway.
@Dan: Have to move. Client wants modernization. I don't like those SET FILTERs either. They were introduced by my predecessor. But they worked.
@Mike: Of course there is IF NOT USED.... in the code. It fell victim to the simplification.

To all of you:
I can't wait replacing the BROWSE, the SET FILTER and the ON KEY LABEL.
And I will base the grid's recordsource on a View.
I won't get rid of the memos yet.
I am hopeful again.
I gonna come back with my experiences (or other questions) in a couple of days.

Have a nice weekend, Martin

 

[SnyAc]

Mike... the reason I have abandoned using memo fields is due to the nature of the application environment that my products are used in. The users have to be assumed to be completely computer ignorant and they often turn off their peer-to-peer server while other computers have the tables open which has the potential of corrupting indexes as well as memo fields. I have automated the implementation of FoxFix to try to correct this if it occurs but have discovered that it was easier to write my own routines to handle the variable length comment fields with a non-memo solution. Since I have implemented this (over 7 years ago) I haven't had a single customer support call that was due to table or memo corruption.

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[mescht27]

The first replacement is done.
Instead of the BROWSE I put in a DO FORM SCXS\OrderGrid.scx.
The grid in there has got
- RecordSource = 'Order'
- RecordSourceType = 1
Some (not all, e.g. Alt-A) ON KEY LABEL moved into KeyPress.
(Surprising was, honestly confessing: The grid didn't stop program execution like the browse. It takes me directly to the READ EVENTS. For you guys that is obvious. For me in the meantime to. (I'm coming from FPW2.6))

But that didn't do the trick yet! C5s stay.

Next step: 2nd BROWSE --> Grid on a local View (eliminating SET FILTER)

Will come back. Martin

 

[Mike Lewis]

Martin,

You're pretty well going along the right path. By eliminating each of the problem areas one at a time, you should reach the stage where the error disappears.

It will be interesting to know the result.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

From the log message you can assume the error is happening in the 2nd Browse window, browsing the Childlist.

As you say it happens when scrolling, it's rather to do with updating the dbf when moving away from the current record. Looks like a corruption of the ChildList table to me. This is not unlikely to happen from time to time, if you access the table without or only with record buffering.

VFP9SP2 may still do the exact same automatic record locking when writing, as FPW does. But nobody really can see under the hood what changed from FPW to VFP9, even though the DBF and CDX format didn't change, this could be incompatible, especially if both versions access the same table.

I'd recommend to reindex and pack memo of the table, better eeven create it new and append data to it from the old file. Then add buffering to the VFP9 version. While that means you'd need to provide a save button to users and they need to do an additional click to save changes, it concentrates write operations in time and if C5 errors then occur at save you also know it's having to do with concurrent write operations.

Bye, Olaf.

 

[mescht27]

Hi guys (and girls!),

the second replacement is done, which means there is no BROWSE involved anymore.

The SET FILTER TO and all that other 'spaghetti code' stayes so far. There is no explicit buffering. The two free tables are the RecordSource for the grids, which are both read-only.

It was tested by a single user today for 3 hours. No single C5 !!!

Allthough it's to early for too much hope, I want to share that starting relief.

Happy Easter, Martin@Vienna@Austria

 

[MrDataGuy]

SnyAc and Mike Issues with Memos.

Well here is a 3rd option that I use. There is only one table in my systems that have memos, a Note table. This Note Table is a 'sub' table to other tables. Also it has a field called fragment that is C-100 ( Could be any size but I found C-100 best for me ) that holds short memos ( ~50% that is all that is needed.) and therefore short notes do not need to be placed in a memo at all. Now if for some reason the memo table gets hosed (hosed = technical term <smile>), yes we lose memo information, but the primary table information is still safe. The flip side is that the memos for all the tables are hosed not just one.

This combined with the fact that 99.9%+ of the time my apps only work with cursors not the actual tables (My framework has a data access class) I have not seen any data corruption in years and years.

I remember the good old days where at the start of the app I would open every table and keep them open to improve performance. Boy did I see data issues doing that! Now to me a USE command in a running application is a Bad, Dangerous, and Unwanted command! I do recognize that some/many/most VFPers may not agree with the no USE stand, but it is mine, and following that thinking has allowed me to write very stable applications.


Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[mescht27]

Hi craigber, MikeLewis and whoever will read that,

the problem is solved. There was no single C0000005 in the past weeks.

For me it looks like calling a BROWSE from another BROWSE caused the error. Turning those into a grid did the trick. I had to deal with the scope of some variables. I did not "Base the grid's recordsource on a View to avoid corruption issues", but would have done if the C5 hadn't disappeared.

Thanks to all, especially to craigber, who pointed to the right direction, Martin

 

[Mike Lewis]

Martin,

Delighted to hear you've got it sorted. Thanks for taking the trouble to let us know the result.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy