>
Well neither is storing valeus in Variants as opposed to strongly typed variables. But does that make VB always faster than VFP? No. John's valid point is that theory means little, real world numbers are the real deal. John's point is that sure, it's more overhead at runtime to compile a statement, but is this overhead really an issue? For everyday operations, I doubt it, and for intensive repetitive tasks, there's always SQLPREPARE.
>

Pefomance is not the only issue. Much of it is managibility. Is the ovehead that signficant? Sometimes it is - but often it is not. This is why performance, by itself, is rarely the reason why folks migrate to SQL.

Stored procs allow more control - better error trapping and handling.


>>
Using RV's requires permissions on tables. There is nothing stopping a person from creating a connection in, say VB or whatever, an issuing delete statement directly against a table.
>
>Uh, how about requiring a valid account for the connection? If the username and password are encrypted and compiled into the exe, there's your protection. The security argument is completely invalid, because the same issues apply to both techniques.
>

This is where Charlie's argument wins Erik. How hard is it to get a valid account - other than sa. And unfortuantely, in many situations, getting the sa password requires no great feat of strength either. With the use of stored procs, I could care less whether you have the password in the query analyzer or not. The deal is, you only have access to the procs - and the procs define what you can do. The security argument is not invalid. Talk to any DBA with his salary/hourly rate.


On another front, SP's allow you to logically partition tables. For example, lets say you have a contacts table with a field called type. Further, lets say you have two types of contacts: customer contacts and vendor contacts with type values of C and V respectively. With stored procedures, you could have "virtual" entities like this:

customer_contacts
vendor_contacts

Underlying these procedures is the same contacts table. These procedures however, provide a logical view. Can I do this with RV's or SPT on the client? Of course I can. However, what if I need to now serve up part of my data to another app, perhaps the web. If I took the stored procedure approach, a signficant portion of my business/data logic is already to go as it is UI-indepdendent. I am doing this for a client via DataClas as we speak. The client using DataClas 2000 (VFP) based for the app and dataclas COM (VB COM Based) for the ASP parts. Each talks to the exact same stored procedures. I only had to write the logic one time. The DataClas COM stuff that is written in VB actually uses the same VFP business objects that are used by the VFP app.

The issue is not whether it can be done on the client v. the database. You can put the logic anywhere. The question is where it should go. If you are not using stored procedures, IMO, you are not working in an optimal fashion. I would go as far as to say you are solving the problem incorrectly. Whether you realize it or not, you are limiting yourself. The limits may not kick in today or tomorrow. If you are using SQL Server, Oracle, etc, why not leverage the platform to the fullest extent?

As far as VFP is concerned, the streets are littered with many failed C/S projects that tried to use RV's or that were "over-thought". RV's literally require you to over-engineer a solution. They require you to work too hard.

As far as whether SP's are better than RV's/SPT, lets just say that business is really good right now with respect to those people that "relied" on commercially available solutions in VFP that have failed because those solutions do not scale to the C/S arena. I don't see this work drying up for a long time. For ones that have worked, I would bet those apps cost 10x more than was required.


For those of you listening in, if you have tried to implement a C/S solution with a commercially available solution in VFP and have found it difficult to work with - go here: http://www.takenote.com/dc2000.htm - we will be glad to help!!