>>>>>>I do understand your arguments, all valid.
>>>>>>
>>>>>>Let me put it an other way with a metaphor.
>>>>>>
>>>>>>Imagine you own a cute renaissance manoir and your neighbor just built a brand-new palace, top energy efficient, very comfortable, build up with concrete, fiber glass and carbon, all 'modern' building techniques.
>>>>>>
>>>>>>Your manoir is not so comfortable but hey, you've spent weeks of your spare time to revamp it, have nice trees grow around it, etc. Your family and you feel at home in there.
>>>>>>But still you fear energy prices will go up and up to prices your budget can't afford.
>>>>>>
>>>>>>What do you do ?
>>>>>>- Build your own palace in the park then demolish your manoir ?
>>>>>> Nope, you don't have budget for both maintaining the manoir AND build a new palace, since you need to live in the manoir meanwhile
>>>>>>- Maintain your manoir with concrete and fiber glass ?
>>>>>> Nope again, you would loose the spirit and the charm
>>>>>>
>>>>>>So you wait until a solution shows up.
>>>>>>The someone drops in and tell you :
>>>>>>"Hey, wait a minute, we're just working on a new material that can fit with ancient buildings and solve your thermal isolation problem"
>>>>>>
>>>>>>At first you don't believe him.
>>>>>>
>>>>>>Two years later you see they are able to isolate a small ancient window. Not good enough for the whole manoir but fair enough to wait for completion.
>>>>>>etc.
>>>>>>
>>>>>>I see many VFP dev. and editors somewhat in this situation.
>>>>>>
>>>>>>Many have 50-100 man-years of VFP code.
>>>>>>Unless someone found it, no magic wand exist to convert that into .net / java / php code in less than the very same investment.
>>>>>>This is economically not viable.for the very simple reason that no client will ever pay for that since it does not bring HIM any additional value.
>>>>>>
>>>>>I see many clients paying to convert from VFP to other platforms. I see no clients paying to convert from anything to VFP.
>>>>
>>>>I don't see any requests to convert anything to COBOL either yet there is a ton of COBOL code still running. I'm willing to bet that there is no urgency for that code to be ported to .NET.
>>>
>>>COBOL is still a viable language.
>>
>>
>> Just like VFP in the right circumstances.
>>
>>
>>Many compilers are still supported including .NET versions.
>>>
>>>>
>>>>My wife is working on a application to be used on a factory floor. Guess what? They wanted it in *cough* Access *cough*!! There's another product that I'm sure filled the "mom and pop" business with no need to jump to .NET
>>>
>>>Access is still viable and supported. Access2010 shipped with Office 2010.
>>>
>>>VFP died at 9.0.
>>
>>And VFP is a way better tool than Access ever could be. What a piece of CRAP. I curse Access every time I had to use it. I say "had to" because I'll never go there again.
>>
>
>I'll agree with that, but Access is still a supported and modernized language. VFP died at 9.0 (there's a theme here).

Theme? As in the crappier product wins like VHS vs Beta?

>
>Of course I consider VFP's file based 'database' a dinosaur. I switched to SQL Server a decade ago and only a couple of times have I been stuck trying to maintain (read that fix the corruption and sources of corruption) VFP apps that used DBC/DBF for data storage. Yeah - I'll get flamed for saying that but it is true, and I do not have corruption issues with SQL Server databases (period).


Obviously your experience with DBFs is different from mine (as I've pointed out previously - pushing past 5 years and not a single "DBF issue" on the POS app and others) and it all depends on the setup and nature of the app. It may be a dinosaur but it is easy to setup and use. I won't flame you for your experiences and I'm glad SQL Server worked out for you,but as we all know, VFP can use it and other "real databases" too. Out of curiosity, what are you fixing regarding the corruption and its source?


>
>The only limits on SQL Server databases are hardware limits (depending on license - even free supports much bigger databases). SQL Server is still a supported and modernized platform. VFP died at 9.0.


VFP died at 9.0 *for you* and M$. It's alive and kicking for others including myself. We can keep this up till the cows come home. Let's just say that you no longer like/develop in VFP because it doesn't meet your needs and have moved on to .NET. Meanwhile I'll keep milking that VFP cow.

>
>
>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>I'm in process of converting my VFP retail applications to .NET. Since my aps all use SQL Server as the database this is fairly easy. I will not start a new VFP application - I think that is a disservice to a client at this time.
>>>>>
>>>>>
>>>>>>So let's wait and support these courageous guys working on our windows ; old fashioned but so charming !