Given the correct table schema (i.e. timestamp(14) and pri key) nine times
out of ten, I have found this to be caused by empty records. They are
usually created before all tables had timestamps or when perusing data from
within Access and inadvertently creating a new record.
Check for empty records.
Pat...
BTW it's not unique to MySQL it appears to be an Access issue.
----- Original Message -----
From: Michael Widenius <monty@stripped>
To: Ram Rajadhyaksha <ramr@stripped>
Cc: <myodbc@stripped>
Sent: Friday, August 13, 1999 5:17 AM
Subject: Access 97 and MyODBC (Agh!)
> >>>>> "Ram" == Ram Rajadhyaksha <ramr@stripped> writes:
>
> Ram> I'm getting the same problems as everyone else with Access 97. The
"can't
> Ram> do blah blah because you and another user are attempting to change
the same
> Ram> data at the same time".
>
> Ram> Here's my table:
>
> Ram>
+------------+---------------+------+-----+---------+----------------+
> Ram> | ID | int(11) | | PRI | 0 | auto_increment
|
> Ram> | COUNTYCODE | char(3) | YES | | NULL |
|
> Ram> | COUNTY | varchar(255) | YES | | NULL |
|
> Ram> | TIMESTAMP | timestamp(14) | YES | | NULL |
|
> Ram>
+------------+---------------+------+-----+---------+----------------+
>
> Ram> ...I think it is configured correctly to use in Access.
>
> Ram> I'm really bummed that everyone is having this problem. MySQL totally
rocks
> Ram> but without a problem-free ODBC driver, it's not nearly as useful.
:-/
>
> Ram> Thanks,
>
> Ram> --Ram
>
> Hi!
>
> Can you try to do a myodbc trace file to check where the problem is?
> This is probably an Access problem; Access probably does an compare
> of the record to see if it's changed but does something wrong when
> doing this. If you have a timestamp column, Access should only
> compare the row timestamp with the old timestamp to verify if the row
> is changed.
>
> We could probably avoid this by having full cursor support in
> MyODBC. We will by the end of this month set this project on Cosource
> or Source-Exchange to get help in doing this (I personally would
> rather work on sub selects than doing ODBC cursors), so we hope to get
> this solved in the near future.
>
> Regards,
> Monty
>
> ---------------------------------------------------------------------
> Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
> posting. To request this thread, e-mail myodbc-thread572@stripped
>
> To unsubscribe, send a message to the address shown in the
> List-Unsubscribe header of this message. If you cannot see it,
> e-mail myodbc-unsubscribe@stripped instead.
>
>
