> You can check the options thru VFP system menu
> 1)"tools"->"options..."->Tab "Data"->item "Buffering",should be OFF better.
> 2)"tools"->"options..."->Tab "Remote Data"->item "Records to fetch at a time","Maximum records to fetch","Asynchronous execution"-be unticked usually.Or you can check the SQl connect handle settings "Asynchronous" and "BatchMode" with SQLGETPROP()
> 3) check if there is any Trigger on the SQL table impacting your Select result.
> I supposed you are quite familiar with them,but easy to ignore checking them.
> To verify the buffering issue,you can also try to execute the SQLEXEC() into different cursors such as test1,test2 ...,and observe the results.
> above is all i can bethink of, just a clue for you.

I think I have resolved the issue. Basically, there seems to be a bug in SQLExec() if I call it from cascading classes.

What I have observed is the following. The data was in fact well written to disk as soon as the hit to the VFP Web Service was done. When doing local VFP SQL, I was able to extract the new inserted data on the following hit to any of the 5 WWC VFP instance I have. But, doing the same SQL under SQLExec() called from cascading class (as I created a sub class of another sub class), made the data to not be visible by all WWC VFP instances. For example, only two out of 5 were seeing the new inserted data. I believe this implementation I did was causing some corruption in the memory where the use of SPT was sensitive to. As soon as I switched back to using SPT from my main class, it started to work ok again.

This is the kind of situation that is really bad. We cannot find the direct cause to the problem. Instead, we have to find a workaround hoping that nothing weird would happen. So far, based on my tests tonight, I seem to be back in good setup with that application. Otherwise, I'll consider what you wrote.

Thanks