Ok, that makes sense.

Now another question.

In the code snippet I posted, there are various properties that would be changed
for each run of the class. For example, I might want only the customer name and
balance on one call, then on another, the entire customer record, or any combination
of fields.

Therefore the CursorSchema, SelectCmd, UpdatableFieldList and other properties would
have to be set before each call. This also seems like a good use of the various
Before methods.

Any thoughts towards this end?

Thanks


>If you are using the CA to pull data, I would think you would want to keep the object around to handle updating the data. Why not use the CA class and its various BEFORE/AFTER events to handle opening/closing connections to the database(s)?
>
>
>
>>If I used CursorDetach, what woudl be the point of leaving the cursor object active?
>>
>>
>>>You can use the CursorAdapter.CursorDetach() method to free the table. But I see no reason you need to destroy the oCursor object. You can connect and disconnect as needed with the CA class.
>>>
>>>
>>>
>>>>>>
>>>>>>1) When the object oCursor is destroyed, the table closes. Any way
>>>>>>to make it persist?
>>>>>
>>>>>This makes sense to me as the lifetime of the CA should be the same as the cursor.
>>>>
>>>>If the cursor object is left open, and it's SQL data, isn't this holding a
>>>>connection to the database? We will want to use disconnected data. It seems to me
>>>>that you would want to call this code in some generic format, only being used long
>>>>enough to return the desire data, and having it persistant would make this difficult.
>>>>
>>>>>