>If you mean converting forward into VFP6 from VFP5, I haven't had any problems. A couple things to note: 1] menus get converted ( the field location in the mnx file is changed from numeric length of 1 to numeric length of 2 ). 2) App's generated by either VFP5 or VFP6 run from VFP6 APP's or EXE's, while VFP5 APP's and EXE's may only reference their own version, ( running a VFP6 APP from a VFP5 APP or EXE indicates that you are referencing a previous version of Foxpro ). IMHO, VFP6 is one of the most compatible full numeric release changes that Fox has made.

I didn't ask the question originally... :)

Someone asked about the consequences of using VFP6 as a command-line maintenance tool for a database accessed by a VFP5 application. My experience has been that it's safe to use for things like PACK and INDEX, but if you modify stored procedures, COMPILE DATABASE, or make changes (like changes in the RI definitions) that forces the stored procedures to recompile, VFP5 won't be able to deal with the stored procedures and triggers in the .DBC.

As to whether the upgrade to 6 from 5 is smooth and compatible, it's open to debate. There are enough issues in the runtime environment to make me cautious about porting solid, working VFP5 apps to VFP6 if there's no added functionality being added that needs VFP6; the memory errors being reported in the development mode, as well as some new and tasty issues for installs, make VFP6 a bit chancy. Since my main interest in VFP6 is for COM development, and the necessary changes to the VFP6 memory environment that would make it useful to me haven't been made yet, I'm continuing to work with VFP 5 with most of my (and my clients) commercial applications until Microsoft comes out with some fixes and addresses the VFP memory model issues. I am doing some in-house development with VFP 6, but as John Peterson pointed out, there are differences in the stability of the development platforms with VFP6 (a simple example came up over the weekend; someone reported a design-time C0000005 error, which apparently is 100% reproducible with a simple test case, but for the life of me, it just won't screw up when I'm running VFP6 on my NT box. In this case, it's good for me (I nearly always develop on a box running NT WS or NT Server) but not so good for developers who do their development under Win95/98.

There's a tremendous amount of good, new stuff in VFP6, but as the product ships now, I'm not sold that it's 100% ready for prime time yet. Ask me again after MS ships a Service Pack specifically for VFP6.