>As for typed vs untyped datasets this is an area where Kevin G and I will 100% diagree here.... But you see we cannot have that discussio here because you have fouhd your strawman in the change tracking which BTW has already been proven exists in ADO.NET and IMO in a much better way.
>
>You need to look at dLinq. If you do, you'll understand my point. At present you have the wrong end of the stick. Sorry to have to say it, but this is the second time you've hit out without basis.

I will be taking a look at dLinq as well as other LINQ stuff real soon now. I don't think that LINQ will help you at all for this stuff. Maybe the entity framework will but that's yet to be determined.

Maybe I missed some part of this thread where you are comparing DLINQ (where the Q stands for Query) to typed datasets. They are TWO seperate technologies altogether. One does is not a replacment for the other. I don't really see dLinq replacing the dataset at all.

>Or do you have a new strawman... sending all columns in an update.
>
>It's all part of the same issue- obviously you don't send all columns if you have change tracking. Change tracking was taken for granted by any VFP'er who ever used a RV. Moving to NET, is it best to drop change tracking as you have done. Presumably you must have a reason to do this in NET and apparently in VFP as well. What is it?

It has nothing to do with VFP or .NET at all. We have an approach that has served us and our clients very well over the years. This approach uses stored procedures and our own custom framework for dealing with stored procedures. Personally I never liked remote which I know you and I have discussed here ad nauseum. I dont really like black boxes that do my updates for me. And IMO the native dataset updating and remote views share the same issue. They are black boxes. I guess I am too much of a control freak to let that go :)

>What happens when you do find a conflict when you make a change has been made under you....
>
>1. You must requery all the data for every row that has a potential change correct ?
>
>Not necessarily correct. For the third time: I think it is reasonable to overwrite changes made to the same field at the same time- but not to overwrite newer changes with stale data. The RV has offered this by default since 1995.
>
I think you overgeneralize here but OK.


>3. Seeing how you use remote views... how do you handle them when schema's change ?
>
>The same way you handle your typed datasets and SPs when schemas change. Lets not forget that it is the RV that has been roundly slated for this schema issue, but the SP and typed DataSet have just as much of an issue. It seems that one is awful and the other is perfectly acceptable.

Lets get this correct:::: I don't use typed datasets. My middle tier is adaptive to changes in the stored procedures and what they return.

I'll concede here that this is probably 2 dogs with different sets of fleas.


>4. Couldnt all the oldval/curval stuff you talk about be handled via a timestamp ?
>
>No. a timestamp says "something" has changed. If I've altered a phone number while somebody else has altered the next of kin, the timestamp is not useful. I expect both edits to be saved withing having to ask for human assistance.
OK.... I see your point here.


>So seeing how I lifted my skirt here please give some details as to your approach.....
>
>You already know what I did in VFP. Take a look at the RV- they include 100% injection protection, change tracking and full control over conflict management.
>
>I suppose I'll be told now that I need to stop looking at things from a VFP perspective and the rest of it, with no attempt to engage the actual issue which is change tracking. Such is life.

Actually I dont think I have ever said that at all. We ALL have different approaches to problems. But... if you do decide to move to .NET you may find yourself trying to stuff a round peg into a square hole.