SQLCache achieves this by using dynamic content caching technology, which eliminates the latency of queries made to remote data sources.
The majority of implementations for ADO is in the creation of dynamically built web pages and it is because of this fact that there is strong focus to using SQLCache in such situations. Indeed, for the purpose of explaining the principles of SQLCache the client/server web model works well.
This said, there are no reasons why SQLCache can not be used elsewhere.
For web sites using ADO, dynamic pages are built by making requests, in the form of SQL commands, of a remote data source (for example, a Microsoft SQL server). Often there is the need for multiple such requests to build a single page. These requests add latency into the web server's ability to build and serve the requested page. This latency is comprised of the time taken for the network "round trips" to acquire the data and the time it takes for the SQL server to service the request. These latencies will increase the busier your site becomes. Furthermore, by adding more front-end web servers to your farm you will only exacerbate the problem because you will be adding to the load placed upon both the network and the back end data server. It isn't long before your end users start to experience script time outs and server too busy messages.
Using SQLCache will enable you to serve more connections, quicker and using less hardware for both your front end and back end servers.