Issue 114026

Summary: Run Query shows list totally filled with result of first row, when selecting from tables with an alias name
Product: Base Reporter: hboie <hans.boie>
Component: MySQL Connector/OOoAssignee: marc.neumann
Status: CLOSED FIXED QA Contact: issues@dba <issues>
Severity: Trivial    
Priority: P3 CC: issues, jhf.remmelzwaal, r4zoli
Version: OOO330m3Keywords: regression
Target Milestone: OOo 3.3   
Hardware: PC   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 111112    
Description Flags
Result of "Run Query"
Result of "OpenQuery"
Result of "Copy Query to Calc"
Result "Copy Query to new table"
document to reproduce the bug case none

Description hboie 2010-08-20 22:38:20 UTC
I run OOO330m3 (Build: 9519) on Windows XP. I connect to a mysql database (mysql
 Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486)). I create a simple
query and when i run the query i get a list which is filled with the result of
the first row (see attachment). When i save the query and run it with a
double-click, i get the same result (see second attachment). When i right-click
the query and copy it and paste it in a spreadsheet, i get the same (see thrid

But if i right-click the query and copy it and paste it as a new table, i get
the right result of the query (see forth attachment)
Comment 1 hboie 2010-08-20 22:39:43 UTC
Created attachment 71227 [details]
Result of "Run Query"
Comment 2 hboie 2010-08-20 22:40:23 UTC
Created attachment 71228 [details]
Result of "OpenQuery"
Comment 3 hboie 2010-08-20 22:41:00 UTC
Created attachment 71229 [details]
Result of "Copy Query to Calc"
Comment 4 hboie 2010-08-20 22:41:40 UTC
Created attachment 71230 [details]
Result "Copy Query to new table"
Comment 5 r4zoli 2010-08-21 08:43:58 UTC
It is a duplicate to issue 113631.
Workaround, run query in direct SQL mode. 

*** This issue has been marked as a duplicate of 113631 ***
Comment 6 Frank Schönheit 2010-09-22 07:43:02 UTC
fs->hboie: If you have any chance, please check whether this issue is solved in
the latest milestone build (OOO330.m8). I *suspect* it is not, since issue
113631 (which this one here is claimed to be a duplicate of) has been fixed in
m7, but we got a similar bug report as this one here, applying to m7. So, to me
this sounds as if this issue here might not be fixed in m7/m8, too.
Comment 7 Frank Schönheit 2010-09-22 07:54:32 UTC
Created attachment 71801 [details]
document to reproduce the bug case
Comment 8 Frank Schönheit 2010-09-22 07:56:45 UTC
found the pattern: the table alias names are the culprit here, without them, the
query works fine. The attached database contains a simple example to reproduce
the issue.
Comment 9 Frank Schönheit 2010-09-22 07:58:24 UTC
the bad news is: the bug still happens in OOO330.m8, where issue 113631 is
fixed. Conclusion: This one here is not duplicate. Reopening it.
Comment 10 Frank Schönheit 2010-09-22 07:59:57 UTC
*** Issue 114658 has been marked as a duplicate of this issue. ***
Comment 11 Frank Schönheit 2010-09-22 08:03:46 UTC
grabbing, will investigate as long as the main developer is not available, to
see if I can fix this for 3.3.
Comment 12 Frank Schönheit 2010-09-22 09:12:41 UTC
works in OOo 3.2.1 => adding keyword "regression"
Comment 13 mdxonefour 2010-09-22 09:55:22 UTC
adjusting target to 3.3
Comment 14 Frank Schönheit 2010-09-22 10:08:15 UTC
fixed in CWS dba33j

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 15 Frank Schönheit 2010-09-23 08:35:01 UTC
fs->msc: please verify in CWS dba33j
Comment 16 marc.neumann 2010-09-27 09:55:24 UTC
verified in CWS dba33j

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System:
Comment 17 r4zoli 2010-10-15 12:15:48 UTC
Something not good, but I'm not sure.

Open attached database.
Open "first row data only"
Run query with UI it gives same results in first two(first) and second(second)
two record.
If you run in "direct mode" gives different records.

May be needs to reopen it.
Comment 18 r4zoli 2010-10-15 12:16:52 UTC
I forget to mention I tested in OOO330m10.
add cc.
Comment 19 Frank Schönheit 2010-10-15 12:36:55 UTC
indeed, the values in the "sub" column are still wrong, though the values of the
other columns are correct now ... re-opening
Comment 20 Frank Schönheit 2010-10-15 12:38:11 UTC
checked in CWS dba33j, where this bug was claimed to be fixed: The wrong data in
the "sub" column was present there, too - something which slipped my both my and
QA's attention :(
Comment 21 Frank Schönheit 2010-10-15 12:39:03 UTC
fs->oj: Could you please have a look at this remaining problem? You know the
code (it's a problem of the newly introduced OptimisticSet) much better than /me
Comment 22 ocke.janssen 2010-10-18 11:42:30 UTC
Fixed in cws dba33k.

The problem is that not all key column(s) of the S table are selected. Therefor
refetching doesn't work. Now the query will return the correct result but isn't
updateable until you insert the ID column of table S. This could also be a work
a round for this issue.
Comment 23 ocke.janssen 2010-10-20 06:25:23 UTC
Please verify. Thanks.
Comment 24 marc.neumann 2010-10-20 07:56:36 UTC
verified in cws dba33k
Comment 25 hboie 2010-10-20 09:14:40 UTC
I tried with 3.3 rc1 and as far as i can see the bug is fixed
Comment 26 r4zoli 2010-10-22 17:30:49 UTC
Checked in OOo 3.3RC2 (OOO330m12), it is OK.