| Bug #8747 | DOUBLE Fields in Access | ||
|---|---|---|---|
| Submitted: | 23 Feb 2005 20:27 | Modified: | 14 Jun 2013 10:24 |
| Reporter: | peter belkner | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S2 (Serious) |
| Version: | MySQL 4.1.10 / MyODBC 3.51.11-2 | OS: | Windows (Windows XP SP 2) |
| Assigned to: | Bogdan Degtyariov | CPU Architecture: | Any |
[23 Feb 2005 22:03]
MySQL Verification Team
I was able to repeat the behavior reported using your table schema but adding a timestamp column resolved the issue: mysql> desc a; +-------+-------------+------+-----+-------------------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+-------------------+-------+ | a1 | varchar(64) | | PRI | | | | a2 | varchar(64) | YES | | NULL | | | a3 | double | YES | | NULL | | | t1 | timestamp | YES | | CURRENT_TIMESTAMP | | +-------+-------------+------+-----+-------------------+-------+ 4 rows in set (0.01 sec) you need to delete the current linked table and re-link it again.
[24 Feb 2005 12:45]
peter belkner
As suggested, executing the following statements makes the problem disapper: ALTER TABLE a ADD workaround timestamp NOT NULL DEFAULT current_timestamp; UPDATE a SET workaround=current_timestamp; Only executing the first statement doesn't work because the ALTER statement seems not to set the default value for the newly created column. The same is true for our original table. Even if this workaraound helps to make the problem disappear it doesn't look like the real solution.
[25 Mar 2005 0:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[30 May 2013 9:55]
Bogdan Degtyariov
the bug needs re-verification.
[14 Jun 2013 10:24]
Bogdan Degtyariov
I was able to modify all the rows in the table without any problems using MySQL Connector/ODBC 5.2.5. No timestamp column was needed for that. Closing bug.
Description: We discovered a strange error since migrating from MySQL 4.0 to 4.1: Some rows of one of our tables where not editable any longer using MS-Access. Now we are able to track down the problem to a small reproducable example: How to repeat: CREATE TABLE a ( a1 VARCHAR(64) NOT NULL , a2 VARCHAR(64) , a3 DOUBLE , CONSTRAINT z_pk PRIMARY KEY (a1) ); INSERT INTO a (a1, a2, a3) VALUES ('a', 'a', 3798180.5); INSERT INTO a (a1, a2, a3) VALUES ('0', '0', 1.5); INSERT INTO a (a1, a2, a3) VALUES ('1', '1', 10.5); INSERT INTO a (a1, a2, a3) VALUES ('2', '2', 100.5); INSERT INTO a (a1, a2, a3) VALUES ('3', '3', 1000.5); INSERT INTO a (a1, a2, a3) VALUES ('4', '4', 10000.5); INSERT INTO a (a1, a2, a3) VALUES ('5', '5', 100000.5); INSERT INTO a (a1, a2, a3) VALUES ('6', '6', 1000000.5); INSERT INTO a (a1, a2, a3) VALUES ('8', '8', 1000000.0); INSERT INTO a (a1, a2, a3) VALUES ('7', '7', 10000000.5); It is not possible to update column a2 for the the rows with column a3 set to 3798180.5 or 1000000.5 using MS-Access because it is claiming that some other user has locked the row. It seems that this has somthing to do with the DOUBLE type and some range of values for it. Our Environment is: * mysql-essential-4.1.10-win32.msi * MyODBC-3.51.11-2-win.msi (from http://www.peterharvey.org/Downloads/MySQL/MyODBC/, earlier versions show the same behaviour) * Windows XP SP 2 * Access 2000 Suggested fix: It seems that this has somthing to do with the DOUBLE type and some range of values for it.