Hi !
It seems that "being more comfortable" means also "being more productive"
in the case. I had very similar dilemma. I chose VFP just because of lack of time to learn new language and make the application in the same period.
I made the application using cursoradapter so it can work with VFP or SQLServer just by switchng one property of my application class. The new VFP8 class (CA) seems to be very good (despite lack of examples). As a result of the work I have also new VFP code that I can use to upsize my other application to SQLServer much more easily than before. I think that for short term projects VFP is still good tool. Also existed VFP application is much more easier to upsize stying with VFP than completly rewrite in a new language. It seems that it is better to give up VFP databases but it can be done still staying with VFP as a tool.

For long distance new projects - I will use C# just because of (as someone said) "writings are on the wall". I can do this without harry, VFP still is in many aspects powerfull and will have next version. NET is much more sexy than VFP but it is still in version 1 with some limitations as regard as productivity.
Maybe it help you to choose right way - good luck !


>Hello Universal Threaders!
>
>Our development team has been Visual Foxpro developers since version 5 and are very much comfortable with VFP. All our previous applications have been done with the native VFP databases (DBF's).
>
>Now, we are embarking on doing a brand new version using 3-tier approach and using SQL databases (but also would like to be able to scale down back to DBF's for small size clients).
>
>It is important that when we decide it would be for both short term and long term benefits, so -
>
>Should we use VFP 8.0 where we would still be comfortable? or move over to C#.net that most "IT gurus" are saying the language of the future?
>
>If we stay on with VFP, would it be not a waste, and just get the components done in VFP and port it over to C# later? (Some where saying a problem with COM wrappers, whatever that is..)
>
>More comments would help us decide... thanks!