Namely this is security risk. But:
Example:
table a table b
id f id f
1 foo 1 foo1
select a.id,a.f,b.id.b.f from a join b on a.id = b.id
-->
1 foo 1 foo1
We select foo and try to change it to 'something else'
1.Check if there are multiple rows:
select count(*) from a where id = 1 and f = 'foo' and ...
all fields of a if there are more.
Abort update with some message if that is > 1
(OK TOAD here has no problem,as I think it creates its own temporary index column, but I could live without that (-:)
2. Else Do update
update a set f = 'something else 'where id = 1 and f = 'foo' and ... all fields of a if there are more.
If referenial integrety or uniquesnes set by indexes or ...
would be breaken, step 2 would fail by db error.
All the rest of bad things not accounted before, are db admin responsibility.
Just some thoughts to make anse think of getting this into heidi (-:
Editing joined resultset
img for ideas for anse
The join resultset appears default 'read only'.
But jou can select either of tables inside join to edit.
Selecting edit mode does not change display of resultset, it only opens fields from selected table for editing.
That leaves little or no possible no seurity risk for breaking data integrity.
The join resultset appears default 'read only'.
But jou can select either of tables inside join to edit.
Selecting edit mode does not change display of resultset, it only opens fields from selected table for editing.
That leaves little or no possible no seurity risk for breaking data integrity.
An example image form SQLyog & usability explanation:
1. join two tables
2. see then, that some latin names (in table aimed to edit data )are probably badly spelled
coz there is no such thing in huge other table where I have
verified latin names
3.Edit first column (the one with probably bad spelled latin names, to right names)
4. usualy there is no mesage, can't find where is log of that updates, but on this image is message coz of violation of indexes
5. As I mentioned somewhere before, and I dont know if sql yog have this feature there should be this logic (leaving out index violation messages):
5.1 if only one record is going to be updated, do it.
5.2 if > 1 will be updated do warning message to user -->
accept/abort
Hope to see that in HeidiSql in my life time (-:
[img][/img]
Please login to leave a reply, or register at first.