>In ADO, you can sequentially move through a recordset - just like you can do in VFP and replace values that way if you like. Or, you can use SQL. The databound grid - which does not work in VFP becuase VFP does not support ActiveX Data Binding is nice. When working with ADO, you really have to let go of using VFP as a front end. Well, not really. You could construct a class that would take an ADO recordset - convert it to a VFP cursor that a VFP grid could bind to. Then, you would need to marshal the changes back to the the ADO recordset from the VFP cursor and then update the backend. While this can be done - it does seem like a roundabout way to do things.

John

Thank a lot for your view as both VFP+VB expert. They are extremely helpful as the whole thread (best regards to all who participate in it).

i shall definitely investigate ADO in the coming days and put VB in the balance for my next project despite VB object programming model is really not on par with VFP.

But who knows FOX programming is quite strong except a few of us here. That drove to HIDE that the product is essentially a VFP make. I just mention "Developper studio 97".

François