Hi Nigel ---

Sometimes it's just as important to know the roles tools play as well as how to code with them. In almost any moderate to large scale system, a single skillset will not suffice. I think the days of the "lone ranger programmer" are dead for all but the smaller applications....it may sound harsh, but if you only know VFP what good are you to the general IT market?

Lets assume a company approaches you to develop a system for 200 concurrent users that has to share data with legacy MVS/DB2 applications and business logic sitting in routines in CICS/COBOL that they don't want to recode. Your average VFP developer with no other skills runs screaming into the night from this. A good developer, VFP or otherwise, might think (as an example only) -- OK, what does the network look like, is there a DB2 gateway in place, do I need to think about thin/fat client, etc etc etc.....

These are the issues challenging developers today. Anyone not willing to think out of the VFP box risks labeling themselves as a coder and *not* a developer...and coders do not make nearly as much as developers....and consultants, who can do the above *and* sell the concept, make much more than both.

Those here who know me know that I'm a bit contemptuous of most VB programmers and this is why: At least VFP coders stuck in the stovepipe understand interface *and* data; VB coders often only know interface.

So, in summary, how much you want to make, salary-wise, is reflected by how willing are you to move up the progression from coder to developer to consultant...and this sometimes demands some hard choices regarding one's favorite tools.

Boy, I sure didn't mean for this to become a soapbox :-D