* Multiple Records Windows or Query Windows

[dbnut]

Not so much a question (now I've found the built-in features to satisfy me), but...

I was looking for ways to have two Records Windows open simultaneously (for example one sorted by birth date, the other by death date) and was poised to enter a new Wish List request.

Then I looked more thoroughly into Custom Queries and discovered that their power far exceeded what can be achieved with the Records Window, so now this gives me an even better-featured "custom records window" display than before. (Previously I used custom queries only occasionally for specific problems).

Then I tried to display the results of two queries in two separate windows for quick switching, but found that the second query opened in place of the first (oh, then I would have to use the records window for one sort and query window for the other???)...

Then, almost by accident I found Tools | Preferences | Workspaces, where the option "Re-use of Open Windows Permitted" for "Query Window" was set to "Yes" (maybe that's the default, as I don't remember changing it).

Well, it's now set to "No" so I can have as many open queries as needed (just like for diagrams) and I'm one Happy Bunny. More praise for Simon Orde.

Just one enhancement would be nice for me: a lock option to prevent accidental re-sorting by clicking a row header.

[tatewise]

That is a clever bit of lateral thinking.
It is worth mentioning that for most Records Window tabs (Individuals, Families, Sources, Media, etc) there is a matching Query Type.
A quick way of creating a Query to match the Records Window columns is to open the Customise Columns window and use Save as Query.
Regarding sorting, I presume you know that Query Columns can have Sort options selected. Then if you accidentally click a column heading, running the Query again will restore the default sort order.

[dbnut]

Well, Mike, time has passed and no-one seems to be interested in this topic . Perhaps there are not so many users doing one-name studies, looking for patterns and connections, trying to piece together relationships amongst a lot of pre-entered data?

Despite the advantage of simultaneous quasi records windows with different sort orders, I've more-or-less resorted back to the Records window because:

1. The number of custom sorted queries was causing clutter.
2. As I added or rearranged columns in the Records Window, similar changes were usually needed to most or all of the queries.
3. Queries have a BIG DISADVANTAGE - multi-column sort order MUST rely on left-right column placement compatible with sorting hierarchy. In contrast the Records Window accepts a sequence of column header right-click sorting from the lowest level to the topmost. You cannot override custom queries in the same way (clicking on a column head just destroys the original order).

So, back to the possibility of multiple record window instances? Better still, a toolbar drop-down with user-defined sort order options. And still better still, enhanced filter options à la Excel Sheet.

Happy New Year

[davidf]

3. Queries have a BIG DISADVANTAGE - multi-column sort order MUST rely on left-right column placement compatible with sorting hierarchy.

But in queries, columns can be repeated and hidden. So copy all your "sort columns", move them to the top (left) and sort them in the required order, then hide them! (use type=Hidden)?

Or have I not understood you bugbear?

[E Wilcock]

Not the time of day but I have only just seen this and would be interested.
I use queries to look at things like emigration and deportation in WW2.
So my method has been to use a query to find the people deported on a certain day or to a certain place (or both) and then put them in a named list. I can choose columns in the named list display and run further queries using that Named list.
I dont think I realised that one can run two queries and have the results of both, but I will look again in the morning.

[dbnut]

Or have I not understood you bugbear?

Well, David, I hadn't thought of hiding columns so that is a plus - many thanks for that. The upshot is it can remove maybe half of my point 3 (not its last sentence). My points 1 & 2 still stand.

Queries still lack the tremendously useful multi-column sort rearrangement possible in the Records Window. Just right-click column headers and choose Asc or Desc for each, moving through the hierarchy from lowest to highest.

I have (relatively minor) reservations about Record Window sorting that don't seem to have been aired here? From what I can make out it appears:

* Sorting on a Year column from a date with Estimated (and maybe About?) may cause unwanted sort behaviour.
* Something similar may happen for columns with some visually empty record values that turn out to be "not quite empty" (perhaps containing a space?).

Both are fairly minor complaints but it could help to be aware of them. The first may be a bug, the second is my carelessness or "user error".

[dbnut]

I dont think I realised that one can run two queries and have the results of both, but I will look again in the morning.

Tools, Preferences, Workspaces, Query Window, Re-Use of Open Windows Permitted: "No". I have "No" also for Diagram windows.

[BTW you mention the ability of queries to put result records into Named Lists. That's certainly not possible in the Records Window, so a great plus point. But I wonder if the software will ever offer full-blown "action queries" (as users of Microsoft Access will appreciate) - for example to update selected fields with a new or modified value. What a treat!]

[LornaCraig]

you mention the ability of queries to put result records into Named Lists. That's certainly not possible in the Records Window, so a great plus point.

You can add records to a named list from the Records Window. Select any group of records and use Edit > Add to Named List

[dbnut]

You can add records to a named list from the Records Window. Select any group of records and use Edit > Add to Named List

Wow, thanks Lorna, I never spotted that - too used to expecting stuff to be available from a context menu, not just from the main menu bar.

it's massively powerful. Though not enough for miserable gits like me. For example, I'd like to duplicate a column value (à la Excel) to a range of rows below. Just one of many features that would help "clean up" data from the bad old days.

[Gowermick]

But I wonder if the software will ever offer full-blown "action queries" (as users of Microsoft Access will appreciate) - for example to update selected fields with a new or modified value. What a treat!]

I don’t get this statement, as queries produce a dynamic resultset.
When you change any field in the underlying data, the resultset field is automatically updated, ( however it does require a rerun of the query to see if the change affects the resultset)

[tatewise]

I think dbnut is asking for cells in a Result Set to allow the value to be modified directly in the Result Set.
Especially the ability to set a selected set of cells all to the same value.
Currently, that can only be done with a plugin.

[Gowermick]

Ah, I get it. Something I always wished it would do

[dbnut]

I think dbnut is asking for cells in a Result Set to allow the value to be modified directly in the Result Set.
Especially the ability to set a selected set of cells all to the same value.
Currently, that can only be done with a plugin.

Yes, Mike, exactly. That was a throw-away remark referring to "updatable" query result sets in general, extended to spreadsheet-like column value copying. A big subject, of course, with many pitfalls and (no doubt) some brutal constraints on what might be permitted in any possible future implementation.

I'm aware there is always the property box route for editing the content of a specific cell but that is (relatively) clumsy and time-consuming (it could benefit from context-switching shortcuts) and even clumsier if the underlying fact does not yet exist in the record concerned.

Of course plug-ins are extremely powerful and ideal for common tasks. For one-off tasks they cannot be the solution for anyone except a real expert.

Anyway this is all off-topic (sorry, entirely my fault) and worth more work to generate a new wish list post.

[davidf]

I am always a bit nervous about actions that will write multiple updates to multiple records!

For instance search and replace can have undesirable effects unless you are very certain about the exact data on which you are operating. (For instance search and replace all Cumberland to Cumbria might make sense if all your data relates to England - but not if hidden in that data you have some US or AU records)

To a degree with products that are aimed at supporting people wanting to do something with IT which is not directly IT related (e.g. Genealogy rather than coding), we may want to protect IT-naive users from some of the powerful tools that we can conceptualise!

That said I would really like a slick means to write out a subset of records (selected by query) to spreadsheet format (already available to CSV via a query), edit them in a/any spreadsheet program and then write them back (based on record ID) over-writing the existing data. That would give the IT savvy the ability to manipulate almost anything (fuelled by enough caffeine). But that should only be an add-in that you add after reading the warnings!

[tatewise]

David, I understand your concern, but it is unfortunate you chose Place names as an example.
In the 'Search and Replace' plugin the Search Scope can be restricted to just Place records involving England.
If the general advice about including the country in a standard column is followed then that is quite easy.

Also, the plugin allows each replacement to be separately confirmed.
The Result Set lists all the changes and if unsatisfactory Edit > Undo Plugin Updates will reverse them all.

Regarding the Query, CSV, Spreadsheet, import using Record Id sequence the 'Flexible CSV Importer' plugin may work.
If the exported CSV format can be arranged to be compatible with the plugin then it may do what you want.

[davidf]

David, I understand your concern, but it is unfortunate you chose Place names as an example.
In the 'Search and Replace' plugin the Search Scope can be restricted to just Place records involving England.
If the general advice about including the country in a standard column is followed then that is quite easy.

Apologies; The dangers of trying to think of a quick widely understood example!

Regarding the Query, CSV, Spreadsheet, import using Record Id sequence the 'Flexible CSV Importer' plugin may work.
If the exported CSV format can be arranged to be compatible with the plugin then it may do what you want.

Thanks, that looks very interesting - as does "Build a Tree from a CSV plugin" (found when I searched on "CSV" in the plug-in store - another example of not knowing what to search for until told the answer!).

I have for some time been looking for a way to quickly rough out Gedcoms for what I call "Family Reconciliations" (e.g. try to take a cross section through say all "Willetts" in "Essex" at a particular time such as the "Parish Record Era") using either downloads from Family Search (with care and scepticism) or a spreadsheet created by cutting and pasting from the likes of FreeReg. Sort of restricted scope One-name studies I suppose.

[dbnut]

Tried to get this back to you last night but ran out of steam but, luckily for me, it needed a lot of revision. In the meantime Mike has offered some great thoughts I will check out later.

I am always a bit nervous about actions that will write multiple updates to multiple records!

Couldn't agree more, and that's what previews and transactions are for .
That's related to a subject I might come back to one day, if I (a) remember, (b) last long enough, and (c) keep my marbles. A lot of ifs there.

To a degree with products that are aimed at supporting people wanting to do something with IT which is not directly IT related (e.g. Genealogy rather than coding), we may want to protect IT-naive users from some of the powerful tools that we can conceptualise!

... stressing the importance, even for the simplest of actions, of understanding what gets saved when and what can be undone. Not sure that's entirely obvious in a few areas?

That said I would really like a slick means to write out a subset of records (selected by query) to spreadsheet format (already available to CSV via a query), edit them in a/any spreadsheet program and then write them back (based on record ID) over-writing the existing data. That would give the IT savvy the ability to manipulate almost anything (fuelled by enough caffeine). But that should only be an add-in that you add after reading the warnings!

Oh damn, you just opened a can of worms from out of my own cupboard, you big thief! .

I'm guessing LDS shoe-horned GED into a tree for the simplest kind of COM. You can at least navigate the single-root data easily on-screen in a tree control (surprise ), but my days writing queries for System 2000 weren’t happy ones. And I don’t know if there’s anything free for Windows to query XML.

Any grown-up model for genealogy (let alone family history) has to be relational (or better). Starting from scratch, you can create some beautiful schemas that in principal model everything you want with minimal redundancy and risk of inconsistency. Then:

• Form-based data entry/edit can be as easy as Family Historian’s while guaranteeing data integrity
• Reference data management is a breeze
• Standard queries give you comprehensive insight into “connections”
• Result tables can link to property boxes or other table views, and open diagrams

A downside is for custom queries, potentially complex and with pitfalls in table joins. However:

• The main user interface could be virtually a clone of Family Historian’s.
• There would be less reliance on plug-ins.
• It should be possible to query (and update) from an external DB with graphical UI.

Data exchange between the relational store and any hierarchy like GEDCOM is not a two-way street. You can in principle “project” the multi-dimensional RDB down to GEDCOM (and export), but not go the other way successfully without a large number of “virtual records” like _PLAC.

Meanwhile, the bottom line for connectivity between FH data and any kind of DB/spreadsheet would need either highly-specialised export and import-update tool pairs from Calico (likely?) or custom plug-ins (not me!), with the ever-present danger that interim updates in FH wreck the integrity.

Hope that makes sense .