LOL,

anything with 'c++ inlined' is probably anything BUT secure :-) So many ways to shoot yourself in the foot with C/C++ and memory management.

+++ Rick ---

>Rick,
>
>The reason we kept using VFP long after it was fashionable, was inline SQL and data manipulation without constant concern about volume. You'll remember the joy of NET equivalents that guzzled resource and brought a PC to its knees. These days with multi-gigabyte memory available, it's feasible using other systems to manage in-memory data exceeding the allowed size of a dbf. Our issue has been that with so much good stuff working well in VFP and VFP Compiler now allowing expression as C++ without needing the VFP runtime, our stuff seems future-proof, can be copied to just about any Windows machine where it will run without needing a forest of files and dependencies and is very easy to secure with C++ inlined into the VFP routines. The next rewrite we do will be in a product that doesn't yet exist- though Lianja is looking extremely close.