Write conflict. very annoying problems!

[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

 

[Jutt]

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.

 

[Guest]

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

 

[Not Me]

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 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