Client/Server Write Conflicts

Over the last 5 years I have developed a very useful set of tools for a Fruit Packing Shed. One tool allows various documents to be printed in relation to a large number of casual employees. We now require multiple entry to enable speedier document delivery. Therefore I have installed a MSSQL server, and upsized etc. However, now when we add a new employee, we get the new employee, however we cannot edit and change after the first creation. NOTE at this stage only one user is accessing the data.

We get a message Write Conflict, another user is editing type of message, and given the opportunity to copy to the clipboard etc. In the Access Help system, it states that no matter what the Record Lock setting is in Access it will revert to the SQL servers settings. What I suspect is happening is that Access is updating the record before we have completed editing, and then compares the data and assumes someone else is editing it, (But of course they are not), and therefore offers a graceful exit. How do we get Access to NOT see the changed record as being edited by someone else?.. very weird question, and I know I am going to enjoy the answer.

Many thanks in advance.

JD

Addendum:
After some trolling about, it appeared that adding a timestamp to a table, helps access handle this type of situation. And it does !!, no other changes to the data table or form were required, I simply added a field to the table on the SQL Server, called timestamp, with the attribute set to timestamp, and voila, editable data again.

Can anyone explain to me why, as I do not seem to be able to find much from M$

There appear to be two possible reasons

1. There is a bit field without a default. Access shows null bit fields as false. When the write back is attempted False <> Null so SQL thinks the record is changed!

2. Some numbers held as floats do not have an absolute value! Again SQL thinks the number has changed!

NOt really explanations - but MS thinks so!