Write Conflict Error

I have a problem in my MS Access 2000 ADP front end that queries a SQL 2000 database whereby I keep getting a Write Conflict Error.

The Write Conflict brings up the following warning:

http://forums.aspfree.com/attachmen...entid=568&stc=1

If I click on Save Record, the same warning comes up, If I click on "Copy to ClipBoard" or "Drop Changes", I get a "Custome Resync" warning box:

http://forums.aspfree.com/attachmen...entid=569&stc=1

I have looked at the MS Knowledge base Article 280730 (http://support.microsoft.com/defaul...Product=acc2000) and I have ensured that any bit datatypes have a default value and I have also added a timestamp to the table design, but I still get the problem.

The table does have some fields with a 'real' datatype, but my understanding from the knowledge base article is that this shouldn't be an issue once I have added the time stamp.

I have run a SQL Profile trace and it appears to me that the update has completed successfully. I have copied the update statement into query analyzer and run it in there. It completes OK, although no records are updated.

Any help would be greatly appreciated.

Cheers,
Rich.

You need to read the article again

"Modify the data type that is in SQL Server to a non-floating point data type (for example, Decimal)."

In otherwords, get rid of the real data type.

To quote the article with regards to the 'real' data type, it says:

To resolve the problem with floating point data types, do one of the following:

Add a timestamp column to the SQL table. (JET will then use only this field to see if the record has been updated.)
Modify the data type that is in SQL Server to a non-floating point data type (for example, Decimal).
Run an Update Query to update the record. You must do this instead of relying on the recordset update

My first action was to add a timestamp column to the table - No luck
Secondly I changed all 'real' data types for decimal - still no luck

So any other ideas?

I racking my brain trying to think of what else could be giving you these problems. Are you using bound or unbound forms?

S_

The form is bound to a stored procedure, although this procedure only queries the single table.

I say bound, I'm afraid I am no expert here. Would I be correct in saying that it is 'bound' if the form.recordsource property is set to the name of the stored procedure?

I believe you problem is that you recordsource is bound to a stored procedure versus a view. I don't beleive that SP/s where ever intended for that use, they can bring you back a recordset, but I believe that the transfer in information in this instance is one way. You need to use a view, or write back you updates using ADO, or through someother kind of connection string

I have never tried doing it that way you are stating, so I can't be sure.

S-

Thanks for your help on this.

I have found the problem !!

We have another CAD application which I have found is updating the same table. It runs alongside my application.

The CAD application updates just two fields on the same table and as I don't need these in my application, I have just changed my SP from Select * to Select specific records (ignoring the two fields that the CAD app is updating).

Good for you.

S-