Hi Jim.

>"Use either the data source of the CursorAdapter object or the data environment.":
>1. What is the difference between the two options? (advantages/problems of either)

If you're using ODBC, rather than having each CursorAdapter hold a connection handle to the ODBC data source, you might want to so that at the DataEnvironment level because it's easier to manage.

>2. Would I ever 'want' to mix the two?... If so, under what circumstances?

Probably not, unless you used different data source types (eg. ODBC and ADO at the same time) for different CursorAdapters in the same DE (which would be unlikely).

>"Use the CursorAdapter class as a standalone class without an associated data environment.":
>1. What is the advantage of using it this way?

You might want to work with data some place that's not a form eg. a class or a PRG.

>2. What do I lose by doing this?

Nothing.

>3. Does a single CursorAdapter class object handle ALL tables I may need or is it one per or...?

You can combine data from more than one table into a CursorAdapter just as you can with a view, but I think it's a lot cleaner for data updates if you use one table per CursorAdapter.

Think of CursorAdapter as the old Cursor class, but on steroids -- the ability to access data from somewhere other than a VFP table or view, plus lots more things.

>"Optionally define the structure of a cursor associated with a CursorAdapter object.":
>1. In what kinds of circumstances would I find this beneficial?

This is beneficial in two ways. First, if the CursorAdapter is in the DE of a form, you'll need to have the CursorSchema property filled out or you'll get an error plus won't be able to drag and drop from the CursorAdapter to the form. The second is when you want to force certain fields to use a certain data type. For example, if some data source has a Double field but you want it to be Currency in the cursor created by the CursorAdapter, you can do that.

>"Control loading of data into the cursor associated with a CursorAdapter object.":
>1. what does this mean and why is it a good thing?

If the CursorAdapter doesn't sit in a form, it doesn't get loaded until you call the CursorFill method. So, you can instantiate the object, set various properties, then call CursorFill when you're ready. Also, you can have it create the cursor without retrieving the data, sort of like the NODATA option for a view.

>"Control how data is added, updated, and deleted using CursorAdapter properties and methods.":
>1. what does this mean and why is it a good thing?

This is a very good thing if you need this capability. For example, if you have a SQL Server table with VARCHAR fields, you don't want data padded with blanks. However, since VFP doesn't have a VARCHAR field, the data in the VFP cursor will be padded with blanks, and those values would be sent back to SQL Server. With CursorAdapter, there are a couple of ways you can control that -- using the ConversionFunc property, which allows you to specify functions to apply to certain fields, or by specifying your own UpdateCmd property, which the exact SQL UPDATE command to use. Also, the BeforeUpdate, BeforeInsert, and BeforeDelete methods fire before anything is sent to the data source, so you can override the SQL statement being sent back if you so desire. Also, you could use different retrieval and update mechanisms. For example, perhaps you want to retrieve the data using a SELECT statement but do updates using a stored procedure. You can easily do that.

>2. How does this differ from the way we did things until now?

Hopefully some of the point I raised above will answer this.

>"Add CursorAdapter objects to containers other than the data environment, such as forms, form sets, and other containers.":
>1. It would be nice to have an example or two of when one might want to do this.

There are lots of times you want to work with data that doesn't involve a form. Say you have an import class that imports data from a source and adds it to a table. That wouldn't necessarily involve a form.

>2. Are there any constraints if one elects to do this?

No.

>"Updates the TABLEUPDATE() function so that it recognizes and handles CursorAdapter objects.":
>This is evident in the write-up for TABLEUPDATE(). But in my reading of all of the CursorAdapter Class stuff, I never saw exactly when or how I was supposed to actually issue TABLEUPDATE(), and I did get the impression that this is done "under the covers" so to speak.

No, it's works exactly the same as it does with any other VFP cursor -- if you have row buffering and move off a changed record, a TABLEUPDATE() is implicitly done. If you have table buffering or don't move off a changed record, you have to explicitly execute TABLEUPDATE().

Doug