Hey David,
Yes I am full of suprises (and by some accounts full of other stuff :))

I do know this we have worked on some big SQL apps and this approach seems to work fine. I did post something to Gary a minute ago discussing why this approach works for us.

IF we had experienced a significant degradation in perormance because of this we would have definitely done it another way. Like you said there are lot of ways to skin a cat.


>JR,
>
>>Why aren't these people using datasets so they can reuse classes in stateless apps rather than writing something new? Is use of SP more important? This is all pretty important stuff for somebody coming from an optimistic locking view/dataadapter environment in VFP.
>
>The answer for why there are umpteen different approaches to tracking changes and updating tables in .NET applications is probably the same reason as why there are umpteen different ways of doing the same in VFP. Because you can. :-)
>
>I, too, was surprised to hear Rod's approach of updating all fields all the time, but who am I to say that it's wrong? I might consider it strange, but I'm sure he'd consider some of my "best practices" as strange, too. However, if I had to update via SPs I might do the same. I imagine that most people using SP's for updating will do just that and send all the fields. Otherwise, the SP code would be much more complex. It just goes to show that there's more than one way to skin a cat.
>
>Frankly, I've used at least four different approaches to updating, change-tracking, conflict checking, locking, and so forth just in the last year, depending on whose app I'm working on or whether I'm rolling my own from scratch.
>
>Interesting discussion, however.