Jim,
by any means I implied it was 'so wrong' as you put it. In the basis of the original question I did not see the logic on having the need of SQL to retrieve uncommitted changes.
But hey, I’m open minded. Let the options roll!

>
>And what's so wrong with that as an option??? I can see someone having an application that allows inputting of "what if" data and then reviewing (potential) results. IF doing the processing using SQL is easier/cleaner that using standard DML commands, why not provide the ability to doso???
>
>There are more people wanting more things in more ways that either you or I can predict, and while many may not make sense on the surface, they likely do make sense to someone, somewhere.
>
>>Jim
>>are you serious, wish list for that?
>>I have to see that. What would be the purpose of using SQL with the uncommitted changes?
>>
>>
>>>>Off course that is not the reason!! For example, if I use browse instead of SELECT, it will show all the changes and even appended record.
>>>
>>>Correct. But the purposeful design of VFP's SQL is to include only "REAL" data in a query result.
>>>
>>>There is a wish list entry asking for an option to specify that UNcommitted changes be includeable too. Maybe you want to add your voice to it!?
>>>
>>>cheers