Bug 278392 - Editing a query should be allowed ONLY in design OR SQL not in both
Summary: Editing a query should be allowed ONLY in design OR SQL not in both
Status: CONFIRMED
Alias: None
Product: KEXI
Classification: Applications
Component: Queries (show other bugs)
Version: 2.4 alpha3 (Calligra 2.4 alpha3)
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Kexi Bugs
URL: https://invent.kde.org/office/kexi/-/...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-24 15:00 UTC by Dimitrios T Tanis
Modified: 2023-04-04 19:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitrios T Tanis 2011-07-24 15:00:34 UTC
Version:           2.4 alpha3 (Calligra 2.4 alpha3) (using KDE 4.6.0) 
OS:                Linux

The query designer seems to lack quite a few features, SQL supports some but changing from one view to the other provides inconsistent data to one or the other view (eg LIKE, etc). That is a SELECT statement in SQL view is overwriten by the one on Design view. The data displayed on the Data view are also inconsistent. Updating both Designer and SQL sometimes results the query displaying results from the statement in Design and other times from the statement in SQL.

As a workaround, until both views (Design, SQL) are consistent with the SELECT features they provide, the user should be allowed to work in ONLY ONE of the two query design modes.

Reproducible: Sometimes

Steps to Reproduce:
Open query at design > add a table and columns
Switch to SQL view > edit sql SELECT statement
Switch to Data view
Switch back to design view, then SQL view

Actual Results:  
Changes to designer are not always reflected in SQL and vice versa.

Expected Results:  
Editing Query Design or SQL, the select statement should be updated on both views.

Other examples are:
1) In a WHERE field = value clause criteria column displayes just the value, however when using WHERE field LIKE value, LIKE is displayed as well (maybe include = in the criteria column? Other operators are displayed).
2) Other SQL predicates are not supported altogether (eg IN, BETWEEN, etc)
3) Bug 277869. https://bugs.kde.org/show_bug.cgi?id=277869
Comment 1 Jarosław Staniek 2011-07-25 19:14:13 UTC
The workaround makes sense but it is not clear if it's good usability-wise.
Comment 2 Dimitrios T Tanis 2011-07-25 19:21:20 UTC
I agree it is not the best solution, still the easiest and most bullet-proof until we can provide consistent features betweeen Design & SQL
Comment 3 Jarosław Staniek 2011-12-18 17:17:20 UTC
Splitted out a 'wish' part of this big to #289293
Comment 4 Jarosław Staniek 2011-12-18 17:18:27 UTC
Ah mistake, sorry, ignore comment #3.
Comment 5 Jarosław Staniek 2012-01-01 21:33:00 UTC
Regarding 
"1) In a WHERE field = value clause criteria column displayes just the value, however when using WHERE field LIKE value, LIKE is displayed as well (maybe include = in the criteria column? Other operators are displayed)."

Operator '=' is the default in the criteria column. So skipping the '=' operator in value 'foo' is equivalent of value ='foo'.
Comment 6 Justin Zobel 2021-03-09 23:43:48 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.