Well stated as usual, John

One more advantage:

If you use SPT with stored procedures, those stored procedures will be useful should you ever switch to another front end, whereas RV's and CA's will not be.




>>What is the best way to handle SQL Server data on a form, with a Remote View, or SQL Passthrough?

SQL Pass-through (SPT) allows maximum flexibility since you can build any imaginable query. RV is less flexible since the field list and WHERE clause generally is fixed, but it has other advantages:

1) SQL Injection-proof
2) Automatic change management
3) Compilation of stereotyped queries by SQL Server, for better efficiency.
4) databinding at design time and retained on requery()

1) matters a lot and is well worth reviewing closely, especially if you are building your SPT by concatenating- e.g.

lcSQL=[select * from dbo.mytable where username=']+lcusername+[']

... that sort of query is highly vulnerable to injection. Injection is easy enough to prevent in VFP by using parameterized queries rather than concatenating SQL- e.g.

select * from dbo.mytable where username=?lcusername

Parameterized queries also are compiled by SQL Server for reuse, leading to better efficiency.

2) Is important as well, since you can edit one or more fields in one or more rows in a RV and have the changed fields automatically saved to the backend, without having to save the whole record/resultset or write your own change management code.

3) is simply that RV's parameterized queries are compiled and reused by SQL Server since (from memory) version 7.

4) is that RVs are very available for grids, controlsources etc at designtime, with the controlsources, designed grid columns etc retained when you requery() the RV. Compare this to the behavior if you use a SPT cursor and recreate it.

>>Also, when you use SQL Server in a Form's Grid control, how much of the data actually comes across the network to the workstation where the user is utilizing a VFP form? Does the data end up in the temp files, until saved and then altered on the SQL tables immediately or later, upon saving?

The data is in a plain cursor that spools to disk as necessary. In a RV, field edits are recorded and uploaded depending on the buffering you select and the update settings in the RV. If (for example) a 1-character field is changed in a RV, by default updating will send back only that one field, which is very efficient and essentially free of charge to the developer. For what it's worth you can mimic this behavior in a SPT cursor or any other sort of VFP cursor: check out cursorsetprop() for this purpose.

Re cursor adaptor: see http://fox.wikis.com/wc.dll?Wiki~CursorAdapterOrNot

"Laugh while you may" -- Captain Charles Morris

[View the parent message of this message] [Reply to this message] [View the map of this thread] [View the map of this thread starting from this message only] [View the map of this thread in the above frame] [View the map of this thread starting from this message only in the above frame] [View all messages of this thread] [View all messages of this thread starting from this message only] [Copy this message header into the clipboard. This is useful if you wish to paste this information into another message for example.] [Email this message to a friend] [Help]

[Watch this thread so all upcoming messages created in it will go directly into your Agent mark messages. This is useful if you wish to collect all messages in regards to a specific thread so you'll have a fast access to it.] [Filter this thread so all upcoming messages created in it will no longer appear in the list of new messages for you]
Save to:
[Save to folder]