>>>>I didn't mean to detract from the cool factor. Anything that makes manipulation of data easier, with less code, is by definition cool. <g> I've been playing with ADO for awhile as it relates to web pages and in many ways, we definitly have more cool commands within FoxPro and I hope Microsoft continues to surprise us with new ones. A native FoxPro recordset object should definitly be on that wish list, on the other hand, maybe it would be possible to create one with what we have? Hmmm... Guess I have something to play with tonight.
>>>>
>>>>Mike
>>>
>>>Hello Mike,
>>>
>>>Any luck with this so far? What about just using, say, COPY TO ARRAY command (and the array may be the some object property)?
>>>
>>>Nick
>>
>>Didn't get to it yet. I teach an ASP class Monday and Wednesday nights and sometimes get just too tied up. Hopefully tonight. But you are on the right track (or at least the track I was going to pursue. Pass the SQL statement to an object, execute the statement in the object to save the data to an array. Provide methods to access a record (row), like MoveFirst, MoveLast, MoveNext, MovePrevious, etc. Events to DELETE, ADDNEW, etc. just like ADO, but using an object that contains the data as an array.
>>
>>Mike
>
>But is it really necessary? You can pass the object with the array somewhere and then convert the array to the cursor again, and use the native FoxPro commands for processing, right?
>
>Nick
The trick is converting the array back to a cursor again. Unless I'm forgetting something (entirely possible), you need to somehome determine the file structure of the cursor coming into the object. Store that structure and then use it again when recreating the array.

FWIW, I've created a test object that takes a SQL string and saves the gathered data into an array. I also had no trouble creating methods to 'simulate' the ADO MoveFirst, MoveLast, MoveNext, MovePrevious, Delete and AddNew. I can't think of a quick way to capture the field types for a generic SQL statement. It might require brute force. Instead of starting with just a SQL string, I guess I could start with an existing cursor or even a table name. That would solve many of the problems. But it would really be more interesting to create the recordset object given a SQL string just like ADO.

Anyway, as this is just an exercise and I have other real things to do, it will go on the back burner for awhile as a fill-in activity. I still am interested in pursuing it, but I don't have enough dedicated time for it right now. If you or anyone wants the object that I have so far to try to solve the create problem, send an email directly to me at mike@micmin.com

Mike A.