Bug 298294 - Kexi query crashes on adding a second relationship
Summary: Kexi query crashes on adding a second relationship
Status: CLOSED DUPLICATE of bug 298197
Alias: None
Product: KEXI
Classification: Applications
Component: Queries (show other bugs)
Version: 2.4.0
Platform: Archlinux Linux
: NOR critical (vote)
Target Milestone: ---
Assignee: Jarosław Staniek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-17 12:02 UTC by Werner Llacer
Modified: 2012-08-11 11:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Sample database (12.00 KB, application/octet-stream)
2012-04-17 12:03 UTC, Werner Llacer
Details
DB with non crashing behavior (14.00 KB, application/octet-stream)
2012-04-17 12:27 UTC, Werner Llacer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Werner Llacer 2012-04-17 12:02:21 UTC
I have a query which involves a master record plus a number of decoding tables.
I create (visually) a query for the master table and add a relationship to one of the tables. Everything works OK
I add a new decoding table, add the new relationship. Edition goes fine
I try to run and kexi crashes 

Reproducible: Always

Steps to Reproduce:
1. Open the sample database attached
2. Open "consulta2" query in design mode
3. Append table "Codigos2"
4. Create a relationship codigos2.campo3  to base.campo3
5  Add field codigos2.campo4 to query
6. Run and ....
Actual Results:  
kexi crashes

Expected Results:  
should return data 

My Archlinux config today is 
Kernel 3.3.1-1-ARCH #1 SMP PREEMPT i686 
Qt 4.8.1-1 
Kdelibs 4.8.2-1 
kexi 2.4.0-1 
sqlite 3.7.11-2


I can't believe people has that much trouble with such a basic functionality as querying like me. Is it my platform or the fact that i'm not using PKs to join tables might be a source of troubles ?


drkonqi info this time is even worse, after 28K lines 
#28609 0xb6358ae2 in ?? () from /usr/lib/libkexidb.so.9
#28610 0xb6359b3b in ?? () from /usr/lib/libkexidb.so.9
#28611 0xac4b4302 in ?? () from /usr/lib/kde4/kexihandler_query.so
#28612 0xac4c868b in ?? () from /usr/lib/kde4/kexihandler_query.so
#28613 0xac4ca84e in ?? () from /usr/lib/kde4/kexihandler_query.so
#28614 0xb75e6a0e in KexiWindow::switchToViewMode(Kexi::ViewMode, QMap<QString, QVariant>*, bool&) () from /usr/lib/libkexicore.so.9
#28615 0x00000002 in ?? ()
#28616 0xb75e76ec in KexiWindow::switchToViewMode(Kexi::ViewMode) () from /usr/lib/libkexicore.so.9
#28617 0x08b7bb38 in ?? ()
#28618 0xb761aff4 in ?? () from /usr/lib/libkexicore.so.9
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Comment 1 Werner Llacer 2012-04-17 12:03:07 UTC
Created attachment 70448 [details]
Sample database
Comment 2 Werner Llacer 2012-04-17 12:27:01 UTC
Created attachment 70449 [details]
DB with non crashing behavior
Comment 3 Werner Llacer 2012-04-17 12:27:40 UTC
I did another test. I've checked the same use case BUT decoding thru PKs (id. the field to JOIN in the decoder table is PK). In this case it works AS expected. 
The fault line is cleary in this case linked to not PK joins.  
I'm pretty much sure that is doable in any SQL database, but never tested in "naked" Sqlite

I've attached a second test database working ok this time. Simple execute query "Consulta1"
Comment 4 Werner Llacer 2012-04-17 12:29:35 UTC
(In reply to comment #3)
> I did another test. I've checked the same use case BUT decoding thru PKs
> (id. the field to JOIN in the decoder table is PK). In this case it works AS
> expected. 
> The fault line is cleary in this case linked to not PK joins.  
> I'm pretty much sure that is doable in any SQL database, but never tested in
> "naked" Sqlite
> 
> I've attached a second test database working ok this time. Simple execute
> query "Consulta1"

NOTE also that for ONLY one relationship it works no matter the field type. The error appears only at the second JOIN
Comment 5 Dimitrios T Tanis 2012-04-20 22:53:25 UTC
Hi Werner.
First of all thank you for your elaborate report. Providing a good report is essential so that we can solve issues as they come in.

Please look into BUG 298197 for some information.

*** This bug has been marked as a duplicate of bug 298197 ***