>Jerry,
>
>Easier to port a less functional product to a more functional product than vice versa.

True. Been there and done that. (It's what the client wanted. He's happy)

> I would think that VB 'cut and paste' logic would port quite well to VFP. By port I mean, mechanically translate. I understand that the resulting code would not be optimium by VFP standards.
>
>Regards,
>Malcolm

I haven't used VB in a while so it may have events and standard methods now that it didn't have when I was using it. VB didn't (doesn't?) have the when and valid events. It doesn't have an integral backend so instead of using the data window and command lline you have to work through an ISQL manager. Very cumbersome. VB's global *.BAS file, BASE indexing, recordset data handling, etc.,,, all make for a manual move.

Taking a dialog from VB to VFP hasn't been down successfully, yet. Manual redraw to required to get it right. VB didn't have anything like VFP Reports, so you either carry CRW along with you but redirect it do .dbf files.

VB didn't have data environments and the database container, unless you were backending with Access.

The list goes on.
I'd start with a fresh anaysis and do a redesign, emphasizing VFP's strengths from the start. I did that when converting Fox 2x to VFP5, because it offered more flexibility and power than the conversion wizard.
JLK