STRUCTURE -TABLE - INSERT location inconsistency (another few clonk moments)

DingBEN commented 4 years ago

Details

UPDATE: 20-02-01 5:19

click on row number in STRUCTURE TAB - row does not highlight CLONK
click on any CELL - row highlights
should highlight when clicking the row num as it does other places. CLONK due to inconsistency
- - The 3652 reference[in issue 3653] points to the 6th msg in this thread, below.
adding a column to table
select row so INSERT(Insert keyboard key) places new column at that location
can't select row, only a column
Press Insert Key and OK on dialog
CLONK Column lands a bottom of list, must use arrow to move it where needed Done with that...
need to see my data in a particular order with only selected columns
CLONK no query tab (forced into a physical order app query This SQL Editor side querying and the LOCKED system default query approach is a KLUDGE Free the user from a forced flow, user is smart enough to handle

Steps to reproduce - self explanatory

Operating system - WIN7 Pro

SQLiteStudio version - 3.2.1

pawelsalawa commented 4 years ago

About insertion position - I agree.

About the query tab - there is DDL tab. In databases, DDL are statements responsible for schema. SQL is responsible for data.

DingBEN commented 4 years ago

POINT NO.1 --------- POINT NO. 2. moot, t.y. ------------- seen that... not the context, I am updating data manually(see below)

DDL is a STRUCTURE type query(cannot be changed), AND not a data one I am in data context at that point, back to the data tab not STRUCTURE. I just modified the STRUCTURE returning to the data panel. I NEED a QUERY TAB so I can adjust how the data is displayed in this particular scenario, ...many other scenarios fit this issue) If I go to an SQL Editor window, I can get the data filtered and displayed in the proper order, but I have no way to update manually, I must yet go to another SQL Editor window to execute a query to update/Insert/etc.

Think about this - I have mentioned it before in prior posts, not exactly the same way but SAME issue. THIS IS A MAJOR HINDERING in this app.

You have not yet answered the issue by giving me a process flow that would be easy to follow intuitively or even if cumbersome.

I think a query tab is all that is needed. ...and when that is in place, the SQL Editor scheme may become deprecated, or left as is for specific or generic jobs, ...I don't see that myself... I would entirely park it, forget it.

Just like I have parked the windows list toolbar ...wastes too much space and FAILS to show items clearly, and fails to draw all windows unless cycled thru to revive the partial toolbar So I use the list under VIEW, but NO right-click context menu to DELETE, etc... must bring back tool bar temporarily to do that!

pawelsalawa commented 4 years ago

You can edit data in SQL Editor. If you execute query and edit its results, unless they are results of computation, i.e. you cannot edit result data that is not directly linked to actual data cell in database. For example:

SELECT column1, column1 / 2 FROM table1;

In this example all cells in first result column will be editable, but none from the second column, because it's result of computation.

There are more cases, when results could not be computed (like if you use GROUP BY or DISTINCT statements, and more). Nevertheless, as long as you return from query data, that is directly linked to actual cells in database, you should be able to edit them, just like you do in Table Window.

DingBEN commented 4 years ago

t.y you for answering... I know you are busy I appreciate all you do, I hope you appreciate my input. Good attempt at providing this go-around... but short of what I see

well no! [ ...picking on only a piece of your statement ...just like you do in Table Window... ] if this was true, then why the need of a separate functionality if they are the same!? so if I try what you propose

no insert button is liveCLONK
Insert keyboard key does not open a new row even after refreshCLONK
editing includes adding rows as well a deleting rows (not according to your definition)CLONK
again, this has to do with the 2 sides you present in the app, one has to remember what side does or doesn't and why would one have to jump to another context while in another contextCLONK That is due to the thinking that a Table window is restricted to a table territory yet the context is DATA! - and YOU HAVE TO CODE those 2 sides, and even you do not remember how more different they are than you propose. I have fallen in that approach enough times long ago to know that if 2 sides are parallel, never program them so that you have to remember that when you change one you must change the other concurrently, instead run them thru the same [that part of the]code.

Old database designs were 1 'rowcentric'... that approach was dumped... systems today are 'datacentric' ... 'windowcentric' is the same KLUDGE... let the query in force be directly accessed fully modifiable within the context, who cares about the window... and having to remember where I can do what vs not in separate windows. Instead, let the functionality be available readily... a query tab would do that

DingBEN commented 4 years ago

UPDATE: see #3653

the partial answer to the dilemma exposed in this thread is the Filter data box
as you can see it is not addressed above, because we are dealing with too many KLUDGES at the same time.

but as I am now using it(testing)... - PROBLEM: typing SQL(partial) in a pigeon hole size box is MURDER!!! having to pan(left-right) to check for errors is ridiculous!

again a full query view in a query TAB would eliminate all this non-sense
tie the Filters to a system Table you name Filters and they can also be reused at will
filter in force can be flagged in the table as active in the active column(boolean toggle)
as to the filter inputs per column gimmick.. TRASH IT! is is useless

pawelsalawa / sqlitestudio