Web Based Sql Server Record Manipulation In Multi-user Environment

I was wondering if you guys might give me some advice on how best to handle a particular scenario i'm struggling with.

I have a client that basically wants web-based-update access to their sql server database.  Specifically, for a group of users to be able to access a page where they select a record for editing.  the caveat is that no two users should be able to pull up the same record at the same time.  Originally I would have thought there was some easier record-locking-mechanism I could exploit within sql server or ado.net itself, but I haven't been able to come up with anything..  so this is my current approach:

The page they use starts-out with basically a blank form.  there are custom-built paging controls at the bottom of the screen.  they click page-forward to begin and a stored procedure is ran to select a record and update a field on that record to indicate "in-process".  when they finish editing the record - or page on to the next record without updating - another stored procedure is ran - updating/resetting the status field on the record appropriately.

The entire page is encapsulated within an ajax.net updatepanel.

The entire page has caching disabled.  This works well in conjunction with the first page being blank.  if they get out of the app and try to get back in by clicking the back button - all they can do is get to the first (blank) page.

A piece of javascript window.onunload clicks a button on the page that releases the record they currently have selected in the event of a re-direct, clicking back, etc.. it appears to work with everything except a window close.  in that case, i have a stored procedure running periodically on the server that checks how long a record has been selected - and if it exceeds the time indicated - resets the record as to allow it to be re-selected later.

In the event of session timeout, they are redirected to another page that tells them their session has timed-out (and since the window.onunload fires - it takes care of releasing the record if they have one on the screen).

The concept seemed to be working well until I started multi-user testing.  Now it seems as if two users time it perfectly - they are actually able to both select the same record.  it happens pretty rarely, but it does seem to happen.  I'm guessing this has to do with how my stored procedure is structured - possibly allowing a tiny-enough window between the record being selected for editing - and the update running to actually status the record as in-process (2 separate sql statements within the one stored procedure).

I believe I also have a found a second quirk in my approach where something is causing the window.onunload event to fire twice in some strange situations..  but that's more annoying/confusing from a logging standpoint than anything..

I've read where people say to ensure you dont update a record that's already been updated - that you should compare the fields before you actually perform the update and ensure they haven't changed since you selected it..  but to me that doesn't solve anything.. if two people select the same record and both spend time working on it - the person that tries to update last has just wasted their time.

I've also toyed with the idea of maintaining a separate table in the database to hold the keys to the currently selected records and use that to keep multiple people from selecting the same record - but honestly i dont know if that approach is any better than what i'm doing now.   

anyway, I was just curious if you guys had any advice in regards to how you'd handle a request like this..  or if you see any obvious problems/fixes with my current approach..

I would greatly appreciate any info you could provide-

thanks-