>>>
>>>I have heard here that you can even get sued by some offended client for 'misguiding' them into purchasing your VFP application
>>
>>I think I'm the only one who has mentioned getting sued in this thread so just in case this is a reaction to my comments I'd just like to clarify I said I be very reluctant to advise a client to put their back end data in DBFs vs SQL Server - and that was in the context of VFP apps. Very different from implying I would be misguiding clients if I got them to purchase a VFP applicaiton.
>
>I might have taken it wrong then;
>However, there are apps which are much better off with DBC/DBFs as they require zero maintenance, then getting
>boggled down into ODBC, server administration etc.
>Now if application does not handle DBC/DBFs correctly is another story. It is true that many people (in early days especially)
>delivered half baked apps which were corrupting dbf's, but this does not mean anything. DBF's can be very productively used
>depending on app requirements. They are infact very safe when used with buffering/transactions implemented throughout.
>This is my personal experience up to now. Only problem appear with high data volumes due to 2gb table limit (scalability) nothing else. For those apps where expected data volumes are high, CS app/SQL Backend architecture should have been choosen from very start.
>
>>> Well designed VFP apps with a SQL data store can be supplemented rather than replaced by modules in other languages for web, mobile, reporting etc. and give clients a better path for evolving while still using the sound, fast VFP app they invested in.
>
>If you ask me, this is about the best possible scenario for smart Foxies!
>You keep VFP/CS app connecting to MSSQL or Oracle that does all heavy lifting on data, while mounting any number of
>glitzy web / mobile interfaces in language of your choice. NET sure have good things to offer there.
>'Conversion' would in this case occur naturally, based on real advantages we start seeing in NET, or other technologies.
>
>What is wrong with 'Blend of Technologies' ? {g}

Exactly. That is what I meant about putting the backend in SQL. If two years from now the client wants all kinds of web stuff or wants cell phone apps against his data or whatever I don't have to scramble around explaining why DBFs don't really lend themselves to that sort of thing without very proprietary kludges from clever foxies, and even then only with limitations. But if my VFP is still handling the desktop/LAN work and they want other goodies, I can just throw on a module in another language looking at the same data. No drama. And they own their data in a format they can report with Crystal or replicate or if they decide to do something else entirely I haven't locked their data into a format that is only handled well through VFP.