>Yeah, we use a parser class that builds the whole sql statement from objects created from metadata. ( I can't take credit for any of it, Mike and Toni wrote it all ) but it has the advantage of being very flexible and incorporating metadata props and any code you want to use in subclassed instances of the cursor, field or parameter objects.

I remember most of it. Although it's now about six years since I last had my fingers in VFE, I still remember how many neat tricks were inside, made possible by the quite strict and straightforward OOP thinking applied.

>And this is my point - that too many VFP developers are not getting out of VFP what they could - especially in coupling it with the power of SQL Server back ends.

I once went through help line by line, and counted how many commands or functions I never used. And I came out good: I did use (at least once!) about 80% of it, and most of the rest was either included for backward compatibility (aka "dBase IV killer features" :), or belonged to the areas I absolutely never used: general fields, ActiveDoc, app wizard framework, menu generator directives.

> I just think if frameworks as an extension of VFP. Everyone cries about no VFP 10 but there are VFP developer environments in the here and now that do things they never dreamed of. If I try to create something in vanilla VFP now I feel like I'm programming in assembler <g>

Feels more like GfA Basic on Atari... small and knowing good. And equally lame in that you can't just start coding in a wasteland, you need so many pieces on which you don't want to waste time. Where's the code I wrote before? Where are my power tools? You can't expect me to open this safe with just hammer and chisel :).