In my business i notice that there is a real madness going on. For every old application that has to be replaced they want to build highly sophisticated c/s solutions. It's not because c/s solves all the problems of file-server based applications, but because the c/s based solutions are more 'MODERN'. I often think many IT managers get horny by hearing the word "Client/server".

Very few people know the real reasons to move to c/s solutions. These are for e.g.:
- OLTP OnLine Transaction Processing
- Transaction log based replication to other servers (often linked by a WAN).
- Reducing network traffic.
- Securing data

OLTP
Even if a file based application use Transactions, They still could fail when writing data to the file-server. Server based transactions are much more safe as they use transaction logs.

REPLICATION
Though you can use replication with file-server based applications, replication of data should be done in transactions (especially when replication over a WAN).

NETWORK TRAFIC
Though it's true that c/s minimize network traffic, much database products (like VFP) use advanced optimizing techniques to reduce network traffic. Also, with 10/100 MB LAN networks this argument is not always a valid argument

SECURING DATA
A SQL-server protects data from corruption, unauthorized access and keeps the data consistent. Though there is some progress by file-server based RDBMSs a c/s solution is more robust.


THE DRAWBACK
But very few c/s solutions are based on these arguments. IT departments are mislead by c/s hype. They don't realize that if they make a c/s solution it often has the following drawbacks.

- They are slower than file server based solutions because the query's are executed on the server. The server could be running several complex query's at the time, while each workstation has enough power to run the same query in less time.

Besides that, you can't use tables natively (USE Table, BROWSE), You have to execute a query which costs much more time than simply use a table. That's why MS recommends not to use a fully c/s solution but to use it along with native lookup tables.

In VFP you can use the Record oriented approach (SKIP, SEEK, SET RELATION, GO TOP, etc) along with the set oriented approach (SQL) which gives you greater flexibility and can improve performance significantly than by using SQL alone.

- They are much more expensive because you have to buy and maintain a extra product (for e.g. SQL server or worse ORACLE) and usually buy extra hardware as it is not recommended to run a SQL server on a primary domain controller. When a business has several departments geographical separated from each other this could be a lot of money.

- Trouble shooting a problem is far more complex (is the problem at the front-end, the middleware, the network, the server) ?

- Development often is far more complex because error handling and maintaining business-rules is a bigger part of your solution. Often you've to synchronize the business-rules on both the front end (or middleware) as the backend. So the costs of building and maintaining c/s solutions get out of control.

CONCLUSION
a c/s solution should only be implemented when a file server based solutions has past it limits. Only when the extra efforts of implementing a c/s solutions are worth it you should use it. Often there are some other alternatives which are much cheaper and easier to use and implement.