>>>>I used VFP for its producditive. C++ compiler doesn't matter for me. I look for PolarFox. It'll run at web, run with one of SQL servers (I can't remember which one was) directly with seek, VFP select commands, new commands...
>>
>>Fair enough. But C++ compilation costs me nothing (apart from a small fee to its author!) and reduces risk of breakage if you use a newer VC++.
>
>Turnaround time in the same ballpark compared to vfp interpreter ? C++ compilation has speeded
> up, but there also must be the step to compile vfp to C++ code. I HATED working through bug lists in (non-Turbo) Pascal and C, as due to compilation times I had to "fix" a couple of issues first in code, then compile, then check all. Working on one bug with immediate testing in interpreters was much better.
>
>>And right now I'm using the x64 IDE that runs quickly and does away with most of the bugs I had experienced in the VFP IDE on Windows 7. One bad bug was the occasional frozen combo in the Find dialog that required a hard stop, losing work. Another was annoying even if you don't lose work: the phantom breakpoint (no breakpoint exists but debug repeatedly stops there anyway) that wastes time when trying to track issues.
>
>If I was still working full time in vfp, sheling out for such fixes might make sense. But unless a new header type for .dbf local munching is introduced, which offers > 2GB files I think 64bit will not be a game changer for giving more speed via less disk usage. Biggest wory is that those new versions did not pass testing runs similar to vfp when new versions were introduced.

2 GB limit doesn't matter so much. .DBF files already like to be flu in a few wind so best thing is move to SQL Server side.