Subscribe to this thread
Home - General / All posts - Selection in Query Result
326 post(s)
#27-Jun-18 18:47

Selection in a query results "table" does not flow through to the underlying table. Should it?

In my own example (screen cap), I am doing a SELECT * from a single table. The results unambiguously contain the btree index column of records from that single table. When I "select" one of the result records, however, the underlying table does not update to reflect that selection.

I understand that, with complex joins, blah blah, selection in the tables invovled in a query might not be feasible. For queries returning the bree index column of a single table, can we have selection in those results flow through?



456 post(s)
#27-Jun-18 21:19

I agree. When I want to find a parcel owned by a certain person, a query seems to be the only way to sort through and find it. Then when you find it...nuthin'. What I do is sort the table and scroll down to the record of interest and select to highlight it on the map. If I want all the parcels owned by one person, I right-click on the name and Filter by that name. Then select all the filtered items and Zoom to Selection on the layer in the Map. You could create a new table based on the query, but when all you want to do is find the item in a drawing, this seems like overkill.

What I find myself wanting is to right-click on the field name and finding a Search or Filter box as an option.


4,899 post(s)
#28-Jun-18 06:37

Should it?

No, it should not. First, thinking of the results table as the same table as one of the tables that participates in a query is defeating the power of queries and the results tables they produce. Second, selection is an ad hoc, casual, interactive tool while SELECT is a gateway to the full power of SQL. [...] If you are leveraging SELECT then use the power it has [...].

The right way to do what you want is to keep a snippet of SQL lying about that you can copy/paste into your queries to create a drawing on the fly from the results. You can then drop that drawing, which shows the resultant geometry that your query picks out/creates, into a map as a layer. Clever symbology, such as larger point symbols in a contrasting colors, can do an even better job than Selection red of highlighting. You can also create drawings dynamically from queries that involve selection. See Example: Create a Drawing from a Query

Use The Force, Luke.

When I want to find a parcel owned by a certain person, a query seems to be the only way to sort through and find it.

No, it is not the only way. I am puzzled you wrote that, given how immediately afterward you described workflow using Filter, and not a query. :-) You could also use the Select panel. You can see the interactivity between a table, a drawing, and the Select panel in the Example: Combining Selections using the Select Panel topic.

If I wanted to find a parcel owned by a certain person, I'd use Ctrl-F for Find or the Select panel. To get more, right-click into the cell that gives the name and use Filter. It's instantaneous. You can then select and see in the map, etc.

What I find myself wanting is to right-click on the field name and finding a Search or Filter box as an option.

If you click on a column head, Ctrl-F automatically by default launches with that field as the target for the Find. It would be interesting to add a checkbox captioned "Filter" next to Whole world only and Ignore case.

[Edited to remove the simile, which sounds too strong in English compared to the use in the original.]


7,972 post(s)
#28-Jun-18 14:49

One of the big reasons we use a separate selection for the result table of a query even if that result table could use a (potentially already existing in the Manifold session) selection for a persistent table is that the result table of a query could be a join from multiple tables.

With each record of such a result table being composed from records of multiple original tables, it would then be unclear whether a particular result record is selected or not (imagine a table with records A, B, C, another table with records D, E, F, and a join table with a single record corresponding to A in the first table and D in the second table - if A is selected and D is unselected, it is unclear whether the record in the resulting table should be selected). This would then call for either (a) disabling persistent selection for result tables of joins even if the joins are all 1:1, or perhaps for (b) adding a separate UI control to select which of the joined tables to use as a source / target of the selection in the result table. Both options reduce the attractiveness of the potential feature significantly.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.