>I'm looking for anyone's opinion on how to do client-server. Here is my problem...
>
>We have a VFP (file-server, i.e. VFP tables) version of our software which has worked for many years and been sold to many users. Most of our application is in several APPs. Our standard reports go into a REPORTS directory on the server, and the user can create his own VFP reports, that go into the CUSTOM directory, again on the server. He can take any of standard reports and copy and modify it. Works great, and users love it.
>
>Now, let's say I go to SQL-server or Oracle. One of our objectives is to reduce client-to-server transmission, of course, for remote sites with low bandwidth. Now, what do I do with these reports? Do I still have shared REPORTS and CUSTOM directories on the server, with a kind of hybrid client-server and file-server architecture? Or should I try to stash the FRX/FRT files in some SQL table?
>
>Also, one technique that worked very well for me was to have a start-up program that the client ran, that checked for newer versions of my application on the server. It was very fast, and the user only saw an impact when I updated the APP on the server. It automated my client updating process. Now, what do I do in an SQL-server environment? Is the same approach viable -- again using a hybrid client-server and file-server approach? And I suppose I could do the same thing for reports; should I?


You could save the specific user's reports to their local computer to cut down on the bandwidth. However, one advantage of keeping them on the server is for backups. If the reports are small in size then I would recommend leaving them on your server.

I wouldn't change how you deploy updates to your application. I'm assuming that the actual APPs run locally on each client machine. Leave your updates on the server. The only time you will have slow-down is when you post an update. As long as that doesn't happen too frequently then you should be fine.