>What kind of client inssist 'NET&SQL' ???

The ones that have add their a$$es bit by problematic .DBF useage, CDX corruption and/or systems written in languages with a dwindling legacy talent pool. Ones that have done "due diligence" when deciding the best direction to go when having a new system developed (where initial development cost isn't the only focus). The one I talked to a couple of weeks ago :)

>Only time I ever heard something like that is in VFP vs NET threads here on UT. Never in real life.

Maybe you all live in an alterative reality in Cyprus :)

>What I always heard was ; 'We want solution yesterday! - tmrw latest.' :))

You get that everywhere.

>In my world (shipping) most of top managers don't know, or want to know what platform or technonlogy is used. My boss calls it 'faxpro', that word is all he care to know, and don't even think of underestimating his nteligence!

Ignorance is bliss - how can a guy who calls Foxpro "faxpro" be expected to know or understand the problems and pitfalls of the underlying technologies his application is developed in. He has to rely on IT people - if all they do is VFP, then the old adage springs to mind - "To a hammer, everything is a nail".

>Now, I would personally feel like cheat, If I told them ;
>- Has to be NET & SQL
>- It will take 1 to N+1 persons/years to develop
>- Will cost us $$$$$ in SQL licences only

I have never told a client that something has to be NET/SQL. They do that all by themselves. Applications take a certain amount of time to develop. If you think they take longer because they are in .NET, you are simply making assumptions. If you want a robust database, then its got to be SQL server/Oracle or similar. DBF's just don't cut the mustard in an enterprise. You can use ADO.Net with any number of "free" ODBC compatible SQL back-ends - it doesn't have to cost. If an application can use DBFs, then it can be done using SQL 2005 Express - that's free too. If I had to write a VFP application again, I wouldn't dream of using .DBFs, not in a million years.

>instead of
>
>- Will take 3 months (on average) to develop and another 3-6 to fully implement/debug/round up.
>- no additional costs (except eventually purchasing latest VFP version)

So you can say ahead of time that every VFP application with take 3 months to develop? Clearly you cannot do this - they are all different yet you are comparing an "(on average)" three month VFP development cycle with "1 to N+1 persons/years" for a platform you have no experience of? Surely, you jest?

>Regarding VFP programmers, I don't se that as good reason either.
>When u hire guy/girl fresh from college, they are mostly dumbsters knowing
>close to nothing (except basics), then you pick one who show some common sense / willingnes to learn - and then you teach them best tool for
>most of the jobs :))

So, you have a mission critical VFP application and you need some additional work done on the system to meet the requirements of a business opportunity that has come your way. You advertise for 3 VFP developers. You get no replies so you go to a job agent and ask them to help. They cannot help because there are no VFP developers on their books. "I know, lets go to a local college, grab 3 kids and teach them VFP". Who knows, in 6-12 months time, they might just be good enough to let near your mission critical application. By that stage, your business opportunity has passed.

As a long term strategy, the college kids approach might be a reasonable idea but the reality is, many companies hire developers (contract or otherwise) when they have a demand and they are released when the job is completed. Hence the need for a "talent pool".

>but I would most probably still do things in VFP :))

Let's hope retirement is not too far off for you :)

>I would be realy happy to jump into those *tough-guys* languages :) Somehow I was always managed to develop what I was hired for with some xbase flavour. (VFP being the best ever)

"To a hammer, everything is a nail" :)

>BTW is there any Skin4VFP written in NET ?

I have no idea.

Best