Multi User Conflict Error ??

  • Thread starter Thread starter Mike Thomas
  • Start date Start date
M

Mike Thomas

In Access 2000, I am getting an error I am seeing for the first time. In a
continuous data subform, when I fill in data in one of the textboxes I am
receiving the error "The Microsoft Jet database has stopped the process
because you and another user are attempting to change the same data at the
same time."

There is no other user, though. I am sure the screen is only ope once, and
tthat I am only running one version of Access.

Also, when I click from the subscreen back into the main screen, I am
getting the dialog box "Another User has changed the data....", then I'm
propted to witre changes, drop changes, etc.

THere is not other user though.

Does anyone know what is going on here?

Many thanks
Mike Thomas
 
Mike Thomas said:
In Access 2000, I am getting an error I am seeing for the first time.
In a continuous data subform, when I fill in data in one of the
textboxes I am receiving the error "The Microsoft Jet database has
stopped the process because you and another user are attempting to
change the same data at the same time."

There is no other user, though. I am sure the screen is only ope
once, and tthat I am only running one version of Access.

Also, when I click from the subscreen back into the main screen, I am
getting the dialog box "Another User has changed the data....", then
I'm propted to witre changes, drop changes, etc.

THere is not other user though.

Does anyone know what is going on here?
Click to expand...

This usually happens when you have code that modifies a record, and you
also modify that same record via the user interface. From the point of
view of the executing code, the other user is you-the-user-interface;
while from the point of view of the user interface, the other user is
you-the-code.

Do you have code in the main form that opens a recordset on the same
table or recordsource query that the subform is based on?
 
Thanks Dirk,

Yes, that's close to what is going on. The user modifies the data in the
parent screen via the user interface. Then, based on what the same users
enters in the subscreen, the subscreen code changes the contents of a bound
text box in the parent screen. When the user clicks back in the parent
screen, the "Write Conflict" box pops up.

DO you know of a works aroud, or a correct way of doing this?

Thanks
MIke Thomas
 
Mike Thomas said:
Thanks Dirk,

Yes, that's close to what is going on. The user modifies the data in
the parent screen via the user interface. Then, based on what the
same users enters in the subscreen, the subscreen code changes the
contents of a bound text box in the parent screen. When the user
clicks back in the parent screen, the "Write Conflict" box pops up.

DO you know of a works aroud, or a correct way of doing this?
Click to expand...

That alone shouldn't cause the problem, but there's probably something
else going on that you haven't mentioned. I'm assuming that when you
refer to the "parent screen" and the "subscreen", you're talking about a
parent form and a true subform -- a form that is displayed on the parent
form by way of a subform control. If that's not what you're talking
about, further clarification is needed.

I'm only guessing at this point, because I don't have all the details,
but you might try having the code in the subform that modifies the
parent record explicitly save that record as soon as the change is made.
Something along the lines of:

' change and save parent record
With Me.Parent
!SomeTextBox = SomeValue
.Dirty = False
End With
 
Thanks Dirk,

Yes I am using a parent form and a true subform -- a form that is displayed
on the parent as a subform control.

The code which updates the text box in the parent form is as follows (in a
sub routine in the subform):

strSQL = "some SQL code"
Set r = db.OpenRecordset( _
strSQL, dbOpenForwardOnly)

If r.RecordCount > 0 Then
Me.Parent.txtCustomerKey = Nz(r!ohCustomerKey, 0)
' Me.Parent.Refresh
End If 'If r.RecordCount > 0

It seems straightforward to me, and I think it is something I have done
elsewhere, but I cannot find an example just now. If anything occurs to you
please let me know.

Many thanks
Mike Thomas
 
Mike Thomas said:
Thanks Dirk,

Yes I am using a parent form and a true subform -- a form that is
displayed on the parent as a subform control.

The code which updates the text box in the parent form is as follows
(in a sub routine in the subform):

strSQL = "some SQL code"
Set r = db.OpenRecordset( _
strSQL, dbOpenForwardOnly)

If r.RecordCount > 0 Then
Me.Parent.txtCustomerKey = Nz(r!ohCustomerKey, 0)
' Me.Parent.Refresh
End If 'If r.RecordCount > 0

It seems straightforward to me, and I think it is something I have
done elsewhere, but I cannot find an example just now. If anything
occurs to you please let me know.
Click to expand...

I don't suppose txtCustomerKey is a Link Master Field to the subform, or
anything like that, is it? That would be bad.
 
Thanks Dirk,

No txtCustomerKey is not a LinkMaster field.

Moving the Me.Refresh line prior to the Me.Parent.txtCustomerKey =
Nz(r!ohCustomerKey, 0) line seems to have 'fixed' the problem, but I would
still like to know what is really going on.


strSQL = "some SQL code"
Set r = db.OpenRecordset( _
strSQL, dbOpenForwardOnly)

If r.RecordCount > 0 Then
Me.Parent.Refresh
Me.Parent.txtCustomerKey = Nz(r!ohCustomerKey, 0)
End If 'If r.RecordCount > 0

Many thanks for all of your help -
Mike Thomas
 
Mike Thomas said:
Thanks Dirk,

No txtCustomerKey is not a LinkMaster field.

Moving the Me.Refresh line prior to the Me.Parent.txtCustomerKey
= Nz(r!ohCustomerKey, 0) line seems to have 'fixed' the problem, but
I would still like to know what is really going on.


strSQL = "some SQL code"
Set r = db.OpenRecordset( _
strSQL, dbOpenForwardOnly)

If r.RecordCount > 0 Then
Me.Parent.Refresh
Me.Parent.txtCustomerKey = Nz(r!ohCustomerKey, 0)
End If 'If r.RecordCount > 0
Click to expand...

Hmm. That line, "Me.Parent.Refresh" would force the parent form's
record to be saved, if it's dirty. But when the focus moved to the
subform, that record would automatically have been saved. Is there
other code on the subform that dirties the parent record? Or, could it
be that the main form and the subform are based on the same table?
Those are the only explanations I can think of, without seeing all the
code.
 
Dirk,

The subform control is populated by a temp table which is requeried every
time the record in the parent form is changed (in the parent form's current
event). There is no LinkMaster field. It looks to me like the parent record
is not automatically saved when focus switched to the subform. I cannot
find any other code in the subform which would change data bound to the
parent form. I will put a stop into the one control which does change
parent data - perhaps it is being executed more than once.

Mike Thomas
 
Mike Thomas said:
The subform control is populated by a temp table which is requeried
every time the record in the parent form is changed (in the parent
form's current event). There is no LinkMaster field. It looks to me
like the parent record is not automatically saved when focus switched
to the subform.
Click to expand...

That would be very odd. Unless this form is corrupt somehow, if the
parent form is dirty before the focus goes to the subform, the record
will be saved. If you see that it is dirty when the subform has the
focus, I believe the subform must have dirtied it somehow.
I cannot find any other code in the subform which
would change data bound to the parent form. I will put a stop into
the one control which does change parent data - perhaps it is being
executed more than once.
Click to expand...

Most peculiar. If you'd like to send me a cut-down copy of your
database, containing only the elements necessary to demonstrate the
problem, compacted and then zipped to less than 1MB in size (preferably
much smaller) -- I'll have a look at it, time permitting. You can send
it to the address derived by removing NO SPAM from the reply address of
this message.
 
Back
Top