Hi Dan!

It's been a while. Anyway, I've done some prototypes and developed some theories regarding how to effectively use ADO within a VFP app.

First off, let's assume that you consider the conversion of an ADO recordset to a cursor and back to be too time-consuming. And let's face it, the only reason you need it is for display and reports. Well, what if I told you I knew of a great ActiveX control out there that worked with ADO to display information? Do you remember the application that beat us this last year? They used a control called Janus GridEx 1.6 something. You can find it at www.componentsource.com. I'm telling you, it's really great. Prevents a lot of headaches on my end.

Anyway, most people simply deal with the connection and recordset objects. However, in theory (I haven't had time to test it yet), if you make proper use of the command and parameter objects, you could theoretically switch between back-ends simply by changing the connection string. (Assuming they're compatible with and have an OLE-DB provider.) Imagine creating "paramterized" recordsets by properly using the command and parameter objects. Since you're basically telling ADO to give you a recordset where this parameter is this value and so on, you don't have to worry about little changes in syntax. Pretty cool concept, huh?

Also, from my own experience, it's much better to have client-side recordsets so that you can "persist" them or save them to disk.

Now as far as reports go, remember how great HTML is in displaying graphical information? Guess what? If you didn't already know, ADO 2.0, which ships with IE5 if I'm not mistaken, can save a recordset as an XML file. You can also create an ADO recordset based on XML. Imagine that. You can actually create a nice looking report without ever having to use the VFP report writer.

You know, the list is endless for possibilities. Anyway, let me know what you think.

>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).
>
>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.
>
>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...
>
>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?
>
>Any help/encouragement at this point would be greatly appreciated.