I was looking for it.

amazing. Indeed it makes sense.

Thanks Jim



>Edgar,
>
>for completeness, it is wish #580.
>
>cheers
>
>>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