Hi Paul,

Try setting the Recordsource for the form to this SQL statement (or to a
saved query with this SQL statement):

SELECT * FROM table WHERE 1=0

This query is guaranteed to return zero records. Remove the code that you
had in the Form_Load event, which was apparently running the query that
grabbed criteria from the combo box.

To address your original question about minimizing Write Conflict errors,
Are there any tables that include memo, hyperlink, OLE Object, or the new
multi-value field (Access 2007 .accdb only)? The reason I ask is that these
fields can cause page locking to be invoked, when you might otherwise assume
that record locking is being used. For JET databases, I have gotten into the
habit of breaking memo fields out to a separate table, with a 1:1
relationship, instead of including the memo field in the same table with
other fields. This way, when a user clicks into the memo field on a form,
they have immediately committed any changes to the parent record and
vice-versa, clicking out of the memo field on the form to any other field
commits changes to the memo data. I base this on the following quote from
Microsoft:

"Also, record-level locking is not enabled for Memo data types."

Source: http://support.microsoft.com/kb/275561, under the title: "Record-level
locking".


Another reason for moving memo fields to their own table is so that I never
run
into this situation:
http://support.microsoft.com/kb/296389

Keep in mind that hyperlink and OLE Object fields involve the same pointer
mechanism that memo fields do, so the above discussion applies to these data
types equally well.

The other thing that I've been doing in all my released applications for the
past couple of years is running code at startup, via an Autoexec macro, that
uses ADO to establish record level locking for the first person to open the BE
database. Subsequent users will connect to the BE database with the same
locking
that the initial user establishes:

http://support.microsoft.com/?id=306435

Michael Kaplan points out on his blog site that when a user selects the option
to use Record Level locking, that this is only a request, not a demand. So, by
using the ADO code in the above article, you are essentially demanding record
level locking.

This KB article clearly states this for the new MVF data type in Access 2007
causes page locking:

http://support.microsoft.com/kb/918578


Hope this helps some.

Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
__________________________________________

"Paul" wrote:

Thanks for the help with this, Jack. The code you suggested:

Me.Recordsource = "SELECT * FROM table WHERE [ID] = " & Me.cboRecords

works great in the combo box's AfterUpdate event because it retrieves the
desired record instantly, and leaves only the single record in the form,
which is exactly what I want.

However, I'm having trouble getting it to work in the form's Load event
because the combo box is null, and the assignment statement above results in
an error since Me.cboRecords is null. Similarly, if I try to put the value
of the combo box in the criteria field of the form's query, the form is
blank because the value in the combo box is null. Is there any way I can
force the combo box to retrieve one of its own records (the first one would
be ok) as soon as the form loads, so it can provide a non-null value for the
ID in the assignment statement and the criteria of the form's query?

I've tried to Requery the combo box before setting the RecordSource of the
form, but that didn't seem make a difference.

Any suggestions how I can overcome problem of the empty combo box when the
form loads?

Paul