Hi,

The move to VFP8 was also a C0000005 festival. Just recompile in VFP8 a project running ok in VFP6.
It's take me one week the to stabilize my project mostly by rewritting my object collections.
The way VFP8 handles object creation/destruction seem's different.

Marcel


>Here is my attempt to translate from Russian a recent message from fido7 newsgroup:
>
>VFP8 and COM+. It's sad...
>
>With a deep regret I inform, that my attempt to move COM+ application to VFP8 has crowned by a brilliant failure, owing to extreme bugness (even by MS criterions) of the last one. After three (!) days of the full-scale experiment with participation of the customer firm, in the file vfp8terr.log it was revealed:
>- 16 fatal errors C00000FD (stack overflow) and
>- 16,620 (!!!) fatal errors C0000005.
>For justice I have to notice, that most part of C0000005 errors are the consequences of the previous errors, but some of them (about 20) are absolutely independent. Especially marked by dislike are commands with macrosubstitutions and SQL queries. But errors were registered in other places too. It is interesting that for vfp8r.dll such problems are not noticed.
>I had to interrupt experiment because of extreme displeasure (passing into threats of physical violence ;-) ) of employees of the customer firm, and had to urgently recompile COM-dll with VFP7SP1. In order to prevent idle talks, I shall notice, that the only change in server code was adding/removing the line ENGINEBEHAVIOR = 70 in config.fpw.
>...
>That's all. Especially distressing is the fact that, according to MS statements, SP release for VFP8 is not planned...
>
>Bye, Serg.
>
>Any comments?