#723 Editable results in query tab

[Anonymous]

Originally created by: andreas....@gmail.com

In rev 1748 it is not possible to change data in a grid if the grid data
was selected via a select statement in the "Query" register of a table.
After pressing ENTER on a selected field, changing the field and pressing
ENTER again the value of that field changes back to the original.

[Anonymous]

Originally posted by: a...@anse.de

That's not a bug, it's intentionally so, to avoid silent data loss bugs like
described in issue #324 .

Status: WontFix

[Anonymous]

Originally posted by: andreas....@gmail.com

Of cause it should not be possible to editors to allow editing data if a unique id
(unique index) was not part of the select satement. But that should be feasible if
there is one? And you can verife that and if here is one and the corresponding field
was part of the select statement you can allow editing?

[Anonymous]

Originally posted by: a...@anse.de

A simple "SELECT bla FROM mytable" is only one of an endless number of different
combinations how a query can look like. Think for example of a JOIN:

SELECT tableA.col1 AS myalias FROM table1 AS tableA, table2 AS tableB WHERE
tableA.id = tB.id

How would you in such a case - technically spoken - compose a UPDATE statement if a
user updates the single field "myalias"? You'd say: No problem, split the SELECT
with some awesome SQL parser which detects everything - the real name of the
database, table, columns to updates in it, of course without having any security
issues in it so the user doesn't run the risk of breaking his data. We don't have
such a parser currently, which is the reason why the query result is blocked for
editing.

[Anonymous]

Originally posted by: rosenfie...@gmail.com

MySQLd doesn't support editable results, which makes this difficult.

It does however return the name of the original table and original column with the
results of a SELECT.  It also tells which columns are key columns.

HeidiSQL could do a SHOW KEYS on the original table after the user query has run,
find out if all key columns are also included in the results in the user query, and
allow UPDATEs via those if so.

This solves the key-finding part of the problem.

Another issue is with derived columns.  They do not necessarily have to be just
aliases.  They could just as well come from a concatenation, algebra, or whatever.

For example, if the query was "SELECT Id, Ships * 50 AS Containers FROM xxx", then
adding a new record and entering 500 in the 'Containers' column should actually
cause the update to post 10 into the original column.

I think this problem might be academic, since MySQLd *probably* does not return the
name of the original column, if the data was at all altered from the original column
data.

This just changes it into another problem though.  What to do with columns for which
there are no "original table" and "original column" information?  I suggest the
editor could just refuse to edit those columns, by refusing to go into edit mode.

All in all, I think it's doable, but would take some effort.

Labels: -Type-Defect Type-Enhancement
Status: Accepted

[Anonymous]

Originally posted by: a...@anse.de

(No comment was entered for this change.)

Summary: Editable results in query tab

[Anonymous]

Originally posted by: adamtho...@gmail.com

This functionality was a great feature and in many instances worked as required -
particularly on a simple select from where statement.

Could it not have a toggle on / off button on the control menu at the top of the
Heidi screen that is set as  enabled=false where a join is used in the select?

[Anonymous]

Originally posted by: a...@anse.de

Issue 1183 has been merged into this issue.

[Anonymous]

Originally posted by: graveen....@gmail.com

Simply, i can understand the problems, but for simple query, it is really interested
to do a select, then clic 'n change.

I think a toggle button, not allowed by default, with a disclaimer could both warn
the possible trouble, and let the user a great flexibility.

[Anonymous]

Originally posted by: rosenfie...@gmail.com

Issue 1212 has been merged into this issue.

[Anonymous]

Originally posted by: a...@anse.de

Issue 1438 has been merged into this issue.

[Anonymous]

Originally posted by: smujohn...@gmail.com

I agree with the people who think this feature should be implemented for simple
queries.  I used it all the time in MySQL-Front (german one) when I was editing and
pasting simple field data for simple queries there were selected by an obvious key
index, etc.  For complex queries and joins, I wouldn't expect it to work, much like
how MySQL-Front won't let you either.

[Anonymous]

Originally posted by: a...@anse.de

Issue 1634 has been merged into this issue.

[Anonymous]

Originally posted by: a...@anse.de

Fixed in [r3295]

Status: Fixed