Thanks, but my mentioning ADO (another developer told me he saw a similar problem in Access using ADO) may have confused you. I'm pulling from SQL Server into a standard VFP cursor, so scope is not an issue. Please let me know if you have any other ideas and thanks for the reply.

>Make sure the variable holding the CursorAdapter object is visible wherever you access the data from the cursor. For example if you are parsing a previously filled ADO Recordset to a VFP cursor with:
>
>

>*  Form Init
>     Local loCAExample
>
>     loCAExample = CreateObject("CursorAdapter")
>     loCAExample.DataSourceType=[ADO]
>     loCAExample.Alias=[MyCursor]
>     loCAExample.CursorFill(,,,myADORS)
>  Return
>

>
>Then referencing "myCursor" in any other procedure than the form Init's will generate the error you mentioned.
>
>HTH,
>
>Enmanuel
>
>>I'm converting a program to use SQL Server on the back end and I've written a test program to ensure that I can talk to SQL Server, fill cursors, make changes, and save the changes to the back end. The program opens the tables, populates some cursors and does some tableupdates. If I just let it run, it gets to one point and says the cursor does not exist, but if I step through it, it works fine. I can reproduce this at will. So it's like VFP is too fast for SQL Server. It's expecting the cursor to be filled, but it isn't. Will I have to put delays in this program to let SQL Server finish its job? Anyone seen this before?
>>
>>Russell Campbell