Hi Dan...

>I am experimenting with ADO as a substitute for remote views in a VFP app we need to move to SQL Server. On the surface it appears a natural fit that would preserve the functionality of our navigation buttons (a key requirement). The use of dynamic, server-side cursors for better performance and automatic refreshing of data is very appealing (at least to my boss).
>

When you refer to navigational capabilities, I am guessing you are referring to navigating through a recordset that is a subset of records on the server, right? With DBF's, when you open a table, the data is there, and you can freely navigate through everything. This does not fit in the C/S model.

>Using a simple VFP form (built from the VFP base classes) I've been able to load and navigate through the cursor, but it is really fighting me trying to do an update. The textbox controlsource properties are all set to reference the recordset object directly (ex: "thisform.orecordset.fields('vendornum').value"). When VFP is first loaded and I edit the textbox contents, then tab off, an error occurs. Cancelling out - close all, clear all, etc - and re-running the form is even more disastrous. The form hangs. You can't close it, or even shut down VFP.
>

I think I know what you are attempting here. The only way I have found ADO Recordsets to work reliably in VFP is to use client-side recordsets. All client-side recordsets are static. In other words, there is no such thing as a client-side dynamic recordset.

>So I have two questions:
>1) Can the recordset.field collection values be manipulated directly like this? John Petersen did a presentation at Devcon that implied that this should work. Or maybe I slept thru a warning or two...
>

While you can manipulate the fields collection by altering the Value Property of each field, directly updating the database through the recordset is loaded with problems. Rather, your best bet is to use the Command Object which references a stored proc. In this scenario, you have a Recordset Object that presents the data to you and a Command Object that handles Update, Insert, and Delete operations. The key is to marshal the field values in the recordset to the parameters collection of the command object. This is a fairly quick task, and one that DataClas 2000 handles for you (see the thread on ADO Management Classes).

>2) Has anyone out there been able to get ADO to work for them at all? This exercise sure has been a PITA. Am I just being dense, or is it really as difficult as it seems?
>

ADO works just fine. The issue is in getting folks to not overuse the Recordset Object.


HTH...