SQL-history: save narrative of selected-group of queries with result-sets

SQL-History - show interleaved query+resultset option , multiple queries+results saved to single file. The docs say: "As you execute SQL statements in the SQL Commander, DbVisualizer saves them as History entries, along with information about the Connection, Catalog, Schema and the execution result." I thought this phrase "execution result" might include the result-set from queries, but it seems not the case. Currently (v8.0.10) the SQL-history does not show result sets for a previously successfully-executed particular query, and separates the individual queries into discrete 'files' when saved via 'Save the current context to a named file'. That is to say you cannot select a group of rows in SQL-history and do a single 'Save' action (when you select 2 or more rows, the Save button gets disabled). Could we have an optional feature, that would (a) allow saving a selected-group of SQL-history queries into a single file, with timestamp information about when they ran AND (b) for that single-file to *also* include the result-set(s) if any, that resulted from each query, appearing after the query text, along with the elapsed time per query, and (possibly truncated) result-set size(row_count). This is intended to help with time-sensitive research (e.g. for a data issue or such like problem) , where the result-set(s) from a whole sequence of queries/procedures needs to be automatically saved along with (preferably following) the query that produced them, in a sequence from start to finish. For example, when examining a potential data issue I may need to make a series of queries, each one producing a result-set and the contents of the result-set determines the next ad-hoc query that I might make. What I'm seeking is a log-file that contains both the queries and their (small) result-sets, in the time order thay they got executed, along with (header/trailer) timestamp when the query executed and its duration(elapsed). The idea is that I can then post that log file to a person who can determine the issue by simply following the log file (but who might not be able to re-run the queries, or might re-run them but get a different result due to time sensitive nature of data etc). So it would behave just like a log of a 'screen' bash session in Linux or a copy/paste of an entire command-line session in db2cmd on Windows. Perhaps there is a simple way to achieve this in the current v8.0.10 version but I do not know a quick and easy way to do it (I think it should not be the default behaviour however).