Hi John,

Interesting thread. Here's my two cents:

1.) Stored procs are more portable. If I create a middle tier to talk with SQL server, I can use the same logic regardless of front end. If I use RVs I have to rewrite the app for a different interface.
2.) If I’m using stored procs, then I’m looking for everything in the same place. Like triggers for example. They’re on the server. They can’t be in VFP since VFP is the interface. Additional data manipulation is simplified by calling other stored procs on the server.
3.) Large apps will bog down with RVs and SPT for that matter due to recompile issues on SQL Server. There are memory issues when there are lots of recompiles going on. This applies to large apps with lots of users so small apps likely won’t see this. In this event it’s important to look at what’s getting recompiled when. Profiler comes in handy here.
4.) I think stored procedures are easier to debug and develop. I see what’s going on and can make other adjustments accordingly.
5.) There was a comment earlier in this thread that stated not every table requires a clustered index, particularly high transaction tables. It is my opinion that each table should have a primary key and clustered index in SQL Server. The maintenance issues for indexes are minimal and SQL Server is built to handle this. Table scans even use clustered indexes.


- Val Matison