Thank you (again) for the information Ratslinger!
Actually I already found your earlier .ods/.odb on the interweb (+ many others - much thanks LibreHive!)
I already have your .ods as a stand alone button-link within this set of forms, precisely for ‘universal export method’.
For the main defined usage in this aspect of my project (which embeds a ‘data-log-to-charts’ workflow) I wanted a link to a single query, rather than than the full query list (the database as a whole has a ‘large’ number of queries dealing with different types of data within broad archaeological-museum-survey-photogrammetery projects)
The data is prepared from a ‘tuple-like object-list’ in the .odb, with a method to populate ‘blank’ .ods templates with columns derived from user defined attributes in the object-list (using string-searches of concatenated ‘free-form’ attributes, essentially populated from combo-boxes controlled by queries+ filter tables) - these attributes can also be created and added to as part of a data-logging process by a user. Attributes can be ignored or variously combined to create working-sets (using Form controls) prior to export to a spreadsheet where templates for graphs and figures (analytical and publication) are prepared from the different user defined ‘object-sets’ (eg ‘bone_’, ‘large_mammal’, ‘pig_tooth’, ‘ceramic:TF48’,’flint-blade:10cm’ etc etc) , for different ‘project-sets’ ( eg sites, areas, trenches, test-pits, years, investigators etc… )
I had a look to see if I could limit the query list in Ratslingers’ macro (or specify a single or short list in some way) … but alas, I know too little
[thinking about it, various parts of this ‘wide’ database could be reconfigured as separate linked .odb projects, rather than as data-sets within a single .odb - this would bundle only the relevant structures to devices (or software instances), and data archived/complied from across the various .odb’s at a latter stage, e.g. data-loggers vs report-writers, image-archives vs specialist analysis…I am not sure if that approach would be overall ‘better’ beyond the save-times/file-sizes of individual .odb - but I hope that illustrates the the kind of task I was trying accomplish !]
[edit: it occurs to me that i could change approach and generate a query with another macro, that uses the string variables (from combo-boxes) for column names derived from user data, and maybe tick-boxes to define AND/OR operators > this could then use something like Ratlingers macro for export with a user-defined query name…however since i actually want sets of csv exports with regular names (so that they are pre-linked and updated on .ods template, or can be found in easily within filesystem) i am not sure this level of functionality is best … at present the export ‘filters’ are essentially special objects in the object-list, using the same accumlated attributes from combo-boxes/queries to define the catagory/attribute-sets for export(eg for figure and graph making) that were used initially when logging the data ‘in the field’]