Why should that make a difference? n-tier design princicples apply the same way way for desktop applications as they do for Web apps.
Tiered is a 'catch' phrase for 'do not xBase'. The reality may be that 90% of the market that does not require enterprise, layered solution with free tables will give full value. MS (and the "tier" shops) made a big deal out of it with the hopes to migrate as many VFP projects to those kinds of architecture so MS could sell SQL and the tier shops could handhold those poor lost VFP developers, whilst assuring they themselves could get a foot in the projects billing cycle. If a project does not need SQL - it don't need it! If a project don't need tiers - it don't need it. MS and the tier shops may desire these items - but 90% of the market does not. 90% of the market is mom and pop. Mom and pop can be almost any company under $500M annual sales. Thats where the emerging market is - that's the market VFP seems perfect for.

I don't care where the enterprise business goes - but to here all this pitch for NOT, you would think every business is an enterprise client - and that just not so. So if 90% of the prospects are mon `n pop, (iow:10% are enterprise - if that high), why does all the talk center on enterprise.

I wish the NOT guys the best. I will use it when I need - but I don't have to go to church to learn it - and - I don't have to pray in public to get others to beleive I have made the "right" choice and jumped on the bandwagon.

A lot is made of reuseability. I do several projects a year for a wide range of applications. They are are all brand new programs. They are custom programs geared to the clients needs and not my need to "reuse" or "prescribe" for a particular kind of solution. IOW: different rules - different end-user sensibilities - Sure - I reuse some pieces from previous projects - but I do not spend my time looking for ways to "scientifically generalize a "module" so I can reuse it (though some of my library seems to have evolved that way.. And despite these shortcomings I can deliver good value (at least my invoices are paid:-),simply because VFP was engineered to help me do it the way I do it.

You're right I'm not about to build a desktop accounting app, but that's not because of the UI issues involved, but because that's way outside of my specialty (accounting?).

I don't know accounting - I didn't take macro economics or physical chemistry courses - but I write apps for those kinds of industries. If a "developer" can read a "help" screen and ask a question on this board - that developer can learn whatever technical issues are needed from publications and can interview the "enduser" as to how the interface needs to behave.

That doesn't mean that I don't build business applications.
I am sure you (and most of us on this board) could build any app the market was willing to buy.

Which goes to my point about NOT and and the big push you tier shop guys are making regarding the very big VFP developers market and VFP project user market you are working to migrate to NOT.

Lets be truthful - the only gain a VFP developer will "enjoy" from learning NOT is that of a "help" desk guy or a contract "laison" guy. All the real NOT development will move off shore. Like Morgan Stanely has done - like Microsoft has done. State side engineers (especially VFP grid heads that move to NOT) will do liitle more than act as a laison with the product development teams over seas.

What I am preaching is this - most of the market right now is mom and pop. The future of multi-cubed tiered-project development shops in the US is dwindling - NOT development in the US will not blossom. The future is in a cottage industry approach. The future for innovation (and wealth creation) are the mom and pop projects (those can grow into a marketable copyright - but development should focus on end user satisfaction). Mom and pop don't need a NOT/SQL solution.

I would think that this assessment of the market would make it obvious that training should be geared to structural and GUI design. I have thought about it - and even outlined a lesson plan. To move a developer guy whose career has focused on maintaining a legacy app or is relegated to coding to someone elses design specs (top down design) to a guy that can go out on the street and do anything (like you and others here) would be expensive (6000-10000$ a head) and time consuming (6 to 9 weeks). A three day seminar won't do it! A three day seminar might be helpful if one is interested in a "laison" position with the product dvelopers overseas - but it won't make anyone a cottage industry and it won't make anyone (the developers) wealthy! And before you get Zin on me - I know wealth is not everything - but it's so much fun to dream that lots of of people (or even just a few) like what you did enough to buy it from you (and you know about that).

You're very quick to jump on issues with non-technical comments, but what do you mean by 'databinding is not meant for developers who work in the trenches' type statement?
When I say data binding I am referring to grids, any control bound to a cursor rowsource or form textboxes bound to a table buffer. Using those features makes applications slow, limits the design paradigm (eg - How will I need to write this app so I can use data binding.) It also means that developers that exclusively defere to binding projects have a reduced exposure to OCX and would be lost when the move or work with other development platforms that do not have "binding" features.

It also means that the foxteam is allowing bugs in controls under situations where binding is not used. VFP 7-9 has a textbox bug the requires a work around int the textbox init event. If the work around is not implemented (in non binded textboxes), changes to the value of that text box will zero or blank out. The "binding" features have affected quality on both sides of the counter.

Personally (and you may have an opinion on this) the over reliance of binding by VFP developers (and even some commercial VFP projects) are central (aside from the tier shops tearing it down) to the negatives VFP has experienced in the market.

What is amazing, despite the tier shop nay-sayers and the over reliance on restrictive "bind" solutions, is how broad the VFP user and developer base is.
Its a big market and it should be worked. But - if you are working it from inside the VFP community you need to be as straight forward as you can - not over embelish the substitute projects or the value of this or that knowledge will have on a VFP developers career.