>>
>>The internet has changed my customers opinion so much, that all they want is more more more. and relying on a network based shared drive solution... Well, is a band aid...the client server, and distributed application market with distributed database shema (sql based) or xml based, is what the future will require. --
>
>
>IMHO I would have to disagree with this. The problem is that SQL based servers are NOT faster than VFP tables until you get to VERY large tables and/or large number of users. I agree with programming to be ready for SQL based backends/client-server, but the cost benefit is just not there. For one, client-server requires usually an even more robust network, and far more powerful servers as well. Unless you a very large userbase, or VERY large databases it's just not cost effective to move to client-server. You would still need to do the same fixes to the network, and then things would probably be fine unless we are talking insane numbers of users (and VFP tables scale to hundreds of users with proper design). Given reasonable network infrastructure, I would put VFP tables up against almost any SQL backend performance wise. The only thing client-server will give is security, data robustness and and increase in query speed over low bandwidth (providing that the return sets are
>fairly small).

-True-

Don't let the hype of SQLServer or any other product bully you into going away from the native database. Even a web app doesn't -have- to have a tiered architecture. For example, if you were using FoxWeb on a single non-clustered server you are limited by the number of channels the server can handle, not VFP limitations. However, if there is any chance you will need to upscale, web enable for bandwidth, or expand the user base, you would be better off changing to a dataserver now. It really depends on your needs in the future. I have written desktop stuff like you have now that will smoke the pants off any ODBC driven client-server application.

BTW, IMHO, ODBC is a bandaid... :)