Hi Al,

one of the very few times I have to try to politely disagree:

NOOOOOOOOOOOOOOOOOOO DAMMMMIIIIITTTT!
Totally wrong mindset!
;-)

Lemme explain in very broad paint strokes.
Why is it typical that next version of vfp runtime is slower
(with the exception of special tuning efforts like Calvin described for vfp7 NTI search IIRC) ?

Because the runtime has been given more functionality the vfp dev can use.

In FPW I used a key table to generate PK with a record for each table.
In vfp we were given autoinc as better alternative.
Running FPW code in vfp misses the possible speedup via autoinc,
as only 1 table needs to be accessed, as header lock is faster.

In vfp the runtime has not only to do everything FPW does in its smaller
runtime, it checks for is it in a dbc, are DBC events defined,
is there an autoinc field defined and jumps over every branch not even available
in FPW.
Vfp offers oodles more functionality -you might add a autoinc similar functionality
in FPW code: define a field name rule, if that such field exists, lock header,,
read current autoinc, increment as 4byte interger, save in header, unlock, add new record
set value of quasi-autoinc field in the 4Byte char, update indices and so on.

Nothing totally impossible for perf hungry coders.
The resulting code probably woul be faster than the
"old FPW Pk-table" way of doing things -
but STILL vfp running all that a C level will run rings around
quasi-identical functionality that "smart coder" implemented in FPW code.

If you continue to code in FPW pattern or paradigma,
you are thumbing your nose at the effort that went into new vfp version.
Yes, more than 60% will not really benefit your specific problem.

But there will be something that lifts your total app to a level much harder
to reach in FPW at a speed you could reach only in C.
Yupp, sometimes it is necessary, but I like
most of that handled by Calvin and others at MS.

As Tamar already hinted at USING vfp benefits like buffering
she is "fair" in not comparing such benefit -
but *offering and not executing such benefits*
is one of the reasons vfp code is slower.

Examples: BINARY index, Table buffering vs. Scatter record buffering,
timers, event binding, standardized hooks in CA, assign/access pattern much better than
Java / C# getter/setter "standard" pattern, better access to C / WinAPI,

(you can stop laughing at my rant now)

best regards
thomas

>All versions of Server 2008 went end of life 2020-01-14 (3 years ago). No-one should be using that platform in production any longer.
>Current versions of Windows Server are 64-bit only and can't run 16-bit FPW apps. FPW apps must be converted to 32-bit VFP to be able to run on a modern Windows platform.
>
>If this is your situation, bear in mind the new server(s) your app will run on will be much more powerful than the current one(s). Even if VFP is, say, 25% slower overall than FPW, it will still be faster on the new hardware than FPW on the old.
>
>In that case, these performance questions are academic:
>- You're committed to switching to VFP
>- You're committed to new hardware
>
>So, believe it or not, a fair comparison is actually between FPW on the old hardware vs VFP on new.