>I have a co-worker with whom I am working on a client/server project. My co-worker has no experience with client/server, but thinks that views should never be used. She beleives the entire application should be written with SLQ Passthrough calling stored procedures. The rational is that when VFP dies, the next client (VB??) would simply pickup by calling the same stored procedures. Beyond that, the backend data would be read only (data warehouse), therefore, the argument for using views at all are completely irrelevant.
>
>Needless to say, I was completely flabergasted. However, her beliefs are taken seriousely by management who doesn't know any better. I tried to explain the power of views, and that all clients access remote data using some form of view. I also argued that SQL Passthrough has a place in client server development, but I would never use it to call only stored procedures to get data to the client.
>
>This was not acceptable. This could completely kill the project. Do other people suffer this kind of insanity? Am I doomed to a life of hell? Can anyone come up with cogent argument of when views are appropriate and why, and when SQL Passthrough is better?


John Petersen, among others has presented some extemely strong arguments against using updatable remote views. (Remote views are fine for read only stuff -- but don't give you enough control in updating process. All sorts of bugs can pop up you can't get up because of the view wrapper. And you can end up with extreme slowness in updates you cannot do anything about. On the other hand I've seen posts by people who have had success using remote view. But using SQL passthrough really does not have to add a whole lot to development time over using views.)

BTW --Don't know if you are using MS SQL server of not -- but my Swiss Army Code on the files section contains a utility that might help dealing with SPT.