Skip navigation links

MySQL Forums :: MaxDB :: Write conflict: Timestamp field with MS Access


Advanced Search

Write conflict: Timestamp field with MS Access
Posted by: ellba ()
Date: January 07, 2006 07:15PM

Dear All,

I have MaxDB (7.6.00.16) installed on a Linux server in a LAN. Via MaxDB ODBC Driver (7.06.00.00) and MS Access 2002 (10.4302.4219 / Office XP SP2) as a Frontend I linked the tables on the MaxDB server. There are no problems with operations (insert, change, delete) with linked tables without a timestamp field. When I insert via SQL Studio a new column (New Column: 'Datatype' := Timestamp & 'Default' := Timestamp) and insert data sets in the linked table the new field shows me the actual date and time of the insert. So far so good. But if I want to 'change' a data set a error is showing up that informs me about a writing conflict: "The data set has been changed since the beginning of the changing process. When you save your data the data of an other user will be lost." The error during the operation 'delete' data is simillar. "The Microsoft Jet-Databaseengine stoppted the procces because you and another user are trying to change the same data." Maybe somebody has an explanation or better a solution for that problem.

Thanks in advance,
Hawky

I forgot to say that with a timestamp field it is still possible to change and delete data sets in SQL Studio. Therefore it has to be a comunication problem between MS Access and the ODBC driver.




Edited 1 time(s). Last edit at 01/09/2006 05:02AM by ellba.

Options: ReplyQuote


Subject Written By Posted
Write conflict: Timestamp field with MS Access ellba 01/07/2006 07:15PM
Re: Write conflict: Timestamp field with MS Access Ulf Wendel 01/09/2006 09:07AM
Re: Write conflict: Timestamp field with MS Access ellba 01/09/2006 10:09AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.