Hi, I assume the bug is located in the join execution for joins via indexed columns. I'll have a look into this code. Thanks for the hint
Kind regards Holger > -----Original Message----- > From: Carsten Wilhelm [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 19. Juli 2006 12:27 > To: Becker, Holger; maxdb@lists.mysql.com > Subject: AW: Migrating from 7.5.00.05 to 7.5.00.26 > > Hi, > > > sound like a database bug. > > > > Perhaps you could post a small example how to reproduce the problem? > > I have investigated the problem a little further: > > 1. When I drop/disable all used indexes, the SQL shows the correct > database rows > > 2. When I enable or create the indexes, the SQL shows no result again > > 3. When I create an identical table (REPORT2) and use this table, the > SQL shows the correct rows > > 4. When I add the same indexes to the new table REPORT2, the SQL shows > no result. > > 5. When I do a normal select (no subselects) which are using > the indexes, > the SQL shows the correct rows - therefore the index itself seems > to be OK. > > This makes me think that something concerning indexing is corrupt in > my database server. Any ideas? Recreating the indexes doesn't seem to > solve the problem. > > Very, very strange behaviour. > > > Also you could try MaxDB version 7.5.0.34 which is already released > > on the download server. Maybe the bug is already fixed. > > Problem stays the same on 7.5.00.34. Sorry. > > Thanks, > Carsten > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
