Write conflict. very annoying problems!

  • Thread starter Thread starter Not Me
  • Start date Start date
N

Not Me

Hi,
I have a form with 3 subforms on it, all 3 subforms have different table
sources, but are linked by the same fields in the main form. For some reason
however, while one of the subforms works fine, 2 of them give me problems!

I can create the record with no trouble, the problem occurs when I move back
into the subform and try to edit. I get an error saying someone else has
altered the record, and doesn't give me the save option but just either copy
to clipboard or drop changes.

As well as this above, once created the records are uneditable/deletable
through their tables in the access mdb! I get an error about the jet
database engine stopping due to someone else working on that record. Even if
I close all the forms down I can't remove the records from the table. I have
to go through an ADP to do this.

any ideas?
Cheers,
Chris
 
It seems that after saving the record it's being
refereshed and the record locking system still thinks
that the record is being edited. After updating the
information try refreshing/requering and see if the issue
is resolved.
 
I had the same write conflict error when using access front end and SQL back end. I had to verify that all bit fields were set with the default of zero in sql and I added a timestamp field to the table. The time stamp field is not referenced but it seems that some data types do not translate properly between the two. Adding the time stamp field resolved the erro

----- Jutt wrote: ----

It seems that after saving the record it's being
refereshed and the record locking system still thinks
that the record is being edited. After updating the
information try refreshing/requering and see if the issue
is resolved
 
Jeff said:
I had the same write conflict error when using access front end and SQL
Click to expand...
back end. I had to verify that all bit fields were set with the
default of zero in sql and I added a timestamp field to the table. The
Click to expand...
time stamp field is not referenced but it seems that some data
types do not translate properly between the two. Adding the time stamp
Click to expand...
field resolved the error

Well I went with defaulting the bit fields to false and that fixed the
problem, nice one! Someone else brought up the use of timestamp in another
group so I might add that anyway just to be safe! :)

Cheers,
Chris
 
Back
Top