Child data grid crashes VFP6

WinXP SP1, VFP6 SP5

I have been tracking down the most elusive bug I've
ever seen. When a particular form was about to be
displayed, VFP would crash with an error in Kernel32.
Finding the cause has been like playing those "bop the
gopher" kid's arcade games - look here, it pops up there
trace here, something else happens. The crash is very
reproducible and I have an exact set of data
that crashes it every time.

I finally tracked it down to a grid
that displays child records from a one-to-many relationship
via the ChildOrder. LinkMaster, and RelationExpr properties.
If I reset these properties to their defaults of (None),
then the form displays without crashing VFP. Obviously the
grid then just shows all the records in the child table
rather than those corresponding to the current parent record.

I could fix this in a number of ways without using the
parent-child grid properties, but I was wondering if anyone
has any idea why in the world this could bring VFP crashing
down. The parent and child tables are temp tables created
and populated before running the form - nothing particularly
interesting about them.

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________

trw7at
Tue Oct 26 17:50:01 CDT 2004

More info on this crash condition...

If I delete one or more records (doesn't matter which
record(s)) from the child table, then pack the table, then
run the form the crash does not occur. Deleting records
without PACKing still causes a crash when the form is run.
PACKing without deleting a record also causes the crash (there
are no deleted records in either table).

In fact, if I do the following it also works:

LOCAL loRec

SELECT childTbl
LOCATE
SCATTER MEMO NAME loRec
DELETE
PACK
APPEND BLANK
GATHER NAME loRec MEMO

DO FORM myForm

So it is not a matter of the actual data in the child
table but some aspect of the DBF, CDX or FPT files
or their headers that is repaired by deleting a record
then packing. These tables are not corrupted by any
power outages or network issues (they are local) or
the VFP crash because I am able to create the tables
fine, then simply not call the form so that I can
examine the tables, make copies for testing, etc.

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________

Olaf
Wed Oct 27 06:02:24 CDT 2004

Hi Tim,

well, if you think it's not a table header defect, why don't
you post your code/form AND data that causes VFP to
crash.

Since VFP6 is rather old, the bug is perhaps already
known and fixed with newer versions. Have you checked,
if this bug still "works" with vfp9beta?
http://msdn.microsoft.com/vfoxpro

You may submit that bug to
http://support.microsoft.com/default.aspx?kbid=867477,
but I think they won't care for VFP6 bugs any more, as
even the extended support ended 30-Sep-2004:
http://support.microsoft.com/gp/lifeprodv

Perhaps the bug is due to several enhancements on
vfp related microsoft components such as MDAC etc.
and although you don't have a newer version of foxpro
those components could be updated by other applications
and affect the functionality of VFP6. VFP is relatively "self
contained" with it's runtime modules, but there may be
some dependency.

Bye, Olaf.

trw7at
Thu Oct 28 10:42:28 CDT 2004

Olaf Doschke seemed to utter in news:esoIxTBvEHA.2804@TK2MSFTNGP14.phx.gbl:

> Hi Tim,
>
> well, if you think it's not a table header defect, why don't
> you post your code/form AND data that causes VFP to
> crash.
>
> Since VFP6 is rather old, the bug is perhaps already
> known and fixed with newer versions. Have you checked,
> if this bug still "works" with vfp9beta?
> http://msdn.microsoft.com/vfoxpro
>
> You may submit that bug to
> http://support.microsoft.com/default.aspx?kbid=867477,
> but I think they won't care for VFP6 bugs any more, as
> even the extended support ended 30-Sep-2004:
> http://support.microsoft.com/gp/lifeprodv
>
> Perhaps the bug is due to several enhancements on
> vfp related microsoft components such as MDAC etc.
> and although you don't have a newer version of foxpro
> those components could be updated by other applications
> and affect the functionality of VFP6. VFP is relatively "self
> contained" with it's runtime modules, but there may be
> some dependency.

The failure does not occur in VFP8 SP1. But that doesn't
help me since this particular application is not going
to be ported to VFP8 anytime soon. I was hoping someone
was familiar with this bug and knew of a simple workaround
or a fix.

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________

Olaf
Fri Oct 29 04:43:35 CDT 2004


"Tim Witort" <trw7at@ixdot.netcomdotcom> schrieb im Newsbeitrag news:Xns959058C72519timwitortwrotethis@207.217.125.201...

Hi Tim,

there are some obvious workarounds not using the
ChildOrder, LinkMaster, and RelationExpr of the grid
and you mentioned it yourself.

Seems like this bug hasn't not got very famous and
noone knows how to simply solve it. Why not use
the SET RELATION command instead of the grids
properties. Or do they cause the same problem.

Bye, Olaf.

trw7at
Fri Oct 29 11:00:43 CDT 2004

Olaf Doschke seemed to utter in
news:#7JmExZvEHA.3612@TK2MSFTNGP09.phx.gbl:

>
> "Tim Witort" <trw7at@ixdot.netcomdotcom> schrieb im Newsbeitrag
> news:Xns959058C72519timwitortwrotethis@207.217.125.201...
>
> Hi Tim,
>
> there are some obvious workarounds not using the
> ChildOrder, LinkMaster, and RelationExpr of the grid
> and you mentioned it yourself.
>
> Seems like this bug hasn't not got very famous and
> noone knows how to simply solve it. Why not use
> the SET RELATION command instead of the grids
> properties. Or do they cause the same problem.

You are correct. There are some obvious workarounds. In fact,
I personally have *never* used these grid properties to implement
a parent-child data display. This particular form was built by
a developer who was with our company for about a year. It is a
fairly complex form and although this person had some good ideas,
his code organization is poor and most of his work is unnecessarily
convoluted.

I'll probably end up scrapping the grid-controlled version and
roll my own. I'm never comfortable giving VFP control over
record pointers and related data. I don't even use relations!

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________