I'm not sure I understand what you're going to gain by moving to Delphi...particularly and old version. If you're going to rewrite your app, you should look at moving away from a two-tier C/S architecture to an n-tier design. VFP can handle this with no problems. You can use a framework like COMCodebook to help out.

>>Don't think you don't need the IDE improvements. They will absolutely will make you more productive..once you get used to them.
>
>Hi Craig,
>
>Thanks for your input.
>
>In fact the reason why we do not care the IDE
>improvements is the fact that we have developped
>a fully generic package (one exe fits many clients)
>where we should have used Delphi or vc++ right
>from the start.
>
>But vfp let us develop a fully workable product despite
>its limited scope of data structures (yet very powerful!).
>
>I like it in fox.
>
>My customers (sizable organisations but too few of them)
>like the product (of course fox did a lot with its gorgeous
>display of c/s data in resizable data-grids)
>
>But We have in a sense overgrown vfp and now plan
>to move the code base to plain old delphi 4 in order to
>generate highly optimized executable code
>(shunting odbc and bde for full speed by the way).
>
>I recently found that, whilst vfp were still way faster
>than the vb6+ado combo, delphi grids are now really faster than
>vfp in our c/s configurations (sybase ASA thru native drivers in
>C++ or delphi).
>
>For a long time, i have thought, possibly wrongly, that vfp
>would compete in the same arena. Clearly the current
>marketing of the product is really suited for
>"ad hoc" development (competition clarion, windev...),
>which is possibly the best martet position for vfp.
>
>In this respect i accept that a powerful IDE may be
>key to most developper here. As far as i am concerned
>i'd develop with notepad or emacs if that fitted...
>
>François
>
>Any feedback on porting complex vfp apps to delphi
>is welcome :)