Hey Jr.
I'll bite

1)I send all columns over the wire when I update.
2)I also send full untyped-typed datasets over the wire as well.
3)We do a lot of work late bound too....

We break all the rules I guess....

So on a technical level.....

Our sending of all columns in an update has the following issues:
1) Amount of data written to the transation log.
2) Some extra network flow over the wire.
3) Some potential IO with index updates.

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.

Or do you have a new strawman... sending all columns in an update.

So JR seeing how you find change traking so important I'll bite here....

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 ?

2. When you do find a problem/conflict what do you do ? Simply throw the entire transaction out and make the user start over ? or do you allow users to make a decision on what data to keep vs throw away ?

3. Seeing how you use remote views... how do you handle them when schema's change ?

4. Couldnt all the oldval/curval stuff you talk about be handled via a timestamp ?

So seeing how I lifted my skirt here please give some details as to your approach.....





>Perry I know you've provided some details in the past but can you please remind me of how you are currently updating data? Are you using SPs? If so, are you sending every field back every time to be updated? I seem to recall you have experience in several tools... do they all handle data differently or are you encountering consistent data principles that cross language boundaries?