>>Make sense. How do you tell what needs to happen to what row after it comes back through?
>
>Hmmmm ... well, not sure I know what you mean. The only thing that would need any attention would be keys (PK and FK) resulting from inserting new rows. We have a methodology for dealing with that ... it's a bit too complicated to give an example, but I can briefly describe it: basically when we insert a new row, we have a singleton key generator class to generate negative keys. When we save the data, if it was a negative client key, we populate a ClientKeys DataSet, mapping the negative key to the actual key that got saved in the database (our stored procs return the PK). Then we pass that ClientKeys dataset (as XML) back through the web service. If everything saves ok, the UI runs a key-matching method (Framework-level method) to replace the negative client keys with the real database values and do a DataSet.AcceptChanges(). Very quick, easy and painless for the app developer.
>
>~~Bonnie

Gotcha. Sounds like fun.