Bug #10530 | MERGEd tables w/DATETIME in primary key -> ODBC call failed in Access link-tbl | ||
---|---|---|---|
Submitted: | 11 May 2005 7:13 | Modified: | 26 Jul 2007 17:30 |
Reporter: | Joe Calkins | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | Connector / ODBC | Severity: | S3 (Non-critical) |
Version: | 3.51 | OS: | Windows (XP sp2) |
Assigned to: | CPU Architecture: | Any |
[11 May 2005 7:13]
Joe Calkins
[11 May 2005 20:05]
Joe Calkins
`NewsTime` is the only field in the primary key in the source table for the MERGE table `nonsymbols`.
[13 May 2005 18:10]
MySQL Verification Team
Thank you for the bug report.
[13 May 2005 19:28]
MySQL Verification Team
The same behavior I got with the MyISAM tables, so isn't related to the Merge tables only.
[30 Sep 2005 13:24]
teej TJ
Using 4.1.7-NT I'm getting the same issue connected from MS Access 2003 SP1 via ODBC MySQL Connector 3.51. I have a small database with one table containing about 30 columns, one of which is a DateTime declared as a primary key. ALTER TABLE `nuclear`.`explosions` DROP PRIMARY KEY, ADD PRIMARY KEY(`ID`, `Codename`, `DateTime`, `Site`, `Classification`, `Purpose`, `Yield`, `DeviceType`, `Country`); Simply trying to open a view to this table causes Access to report "ODBC call failed". If I remove the DateTime field from the Primary Key list on MySQL server, Access can successfully read the table. ALTER TABLE `nuclear`.`explosions` DROP PRIMARY KEY, ADD PRIMARY KEY(`ID`, `Codename`, `Site`, `Classification`, `Purpose`, `Yield`, `DeviceType`, `Country`);
[24 Oct 2005 22:46]
Peter Harvey
I am not able to reproduce these problems. But this can mean that I am not quite getting it or that c/odbc v3.51.12 fixs them. The latter is quite likely since it has fixs for working with date/time and for determining the root table name. Please try Connector/ODBC 3.51.12 from www.mysql.com.
[26 Jul 2007 17:30]
Jim Winstead
Going with what Peter Harvey said. This bug has likely been fixed since reported, but the bug also does not have enough information for verification. (For one thing, the example table does not have a primary key.)