DAO Recordset: Getting by dirty records

[Megalog]

Hey all, I have a minor issue I'm trying to figure out (using Access 2007).

I'm using a DAO recordset to update a table ("Writeups") , with the results of a bunch of functions I've written up over the last few days. It all works great, except that when we run it while employees are logged in, there's the possibility of a write conflict on their end if they happen to be working on the form.

Is there a way for me to detect if that record is currently open elsewhere? I understand the 'dirty' event is a form-level property, so I wouldnt be able to actually see if someone has changed anything on the client side before they saved the record.

Ideally we want to avoid the end user getting the write conflict dialog box by skipping the update to that record during this recordset procedure.
These are the variations I have tried so far with no luck:

Set rstBatchSeek = CurrentDb.OpenRecordset("Writeups", dbOpenDynaset)
 
Set rstBatchSeek = CurrentDb.OpenRecordset("Writeups", dbOpenDynaset, dbSeeChanges)
 
Set rstBatchSeek = CurrentDb.OpenRecordset("Writeups", dbOpenDynaset, dbSeeChanges, dbPessimistic)

The dbSeeChanges value sounds like the answer to this, but it didnt do anything different.
From the help file: dbSeeChanges - Generates a run-time error if another user is changing data you are editing (dynaset-type only).

Any tips would be appreciated!

[Delerna]

Maybe you could arrange the users database to update a flag to value 1 when they move to a record and back to 0 when they leave it

Your update routine could then exclude everything that has the flag set

Just a suggestion ???

[Megalog]

Maybe you could arrange the users database to update a flag to value 1 when they move to a record and back to 0 when they leave it

Your update routine could then exclude everything that has the flag set

Just a suggestion ???

I had considered that.. but our form is set up to save a copy of the current record to a history table whenever a user makes a change and saves the record. If I implement that flag, then everytime a user simply cycles through the records they would be creating a history trail.

This is a split db btw.