<p>I'm building a .NET client application (C#, WinForms) that uses a web service for interaction with the database. The client will be run from remote locations using a WAN or VPN, hence the idea of using a web service rather than direct database access.</p>

<p>The issue I'm grappling with right now is how to handle database concurrency. That is, if two people from different locations update the same data, how do I deal with it? I'm considering using timestamps on each database record and having that as part of the update where clauses, but that means that the timestamps have to move back and forth through the web service interface, which seems kind of ugly.</p>

<p>What is the best way to approach this?</p>

I don't think you want your web service to talk directly to the database.  You probably want your service to interact with some type of business components who in turn interact with a data access layer.  Any concurrency exceptions can be passed from the DAL up to the business layer where they can be handled so that the web service never has to see the timestamps.
But if you are passing something like a data table up to the client and you want to avoid timestamps, you can do concurrency checking by comparing field by field.  The Table Adapter wizards generate this type of concurrency checking by default if you ask for optimistic concurrency checking.