I'd like to share my thoughts about possible direction of further zmsql development and how do I see what might be ultimate goal.
As I alredy mentioned, janSQL engine currently executes sql queries on csv files. The ZmQueryDataset than loads the resultset into itself, as in-memory dataset (TBufDataset descendent). However, janSQL might be reworked to query memory datasets instead of csv files. JAn Verhoeven clearly had it in mind, since there are relicts of unfinished work in the janSQL code.
We have great components (fpspreadsheet) to work with spreasheets. Spreadsheets can be easily exported to .csv files. ZMConnection defines zmsql database as a folder containing csv files. It is easy to program iteration through all spreadsheet files in the ZMConnection "database" folder and to export all spreadsheets into corresponding csv files. This way, we can execute sql queries on spreadsheets, indirectly, by intermediate exporting to corresponding csv files.
Actually, I have already done this, but feel uncomfortable with this intermediate step of exporting spreadsheets to csv files, then querying csv files, loading resultset into ZMQUeryDataset then exporting to csv. files then loading to spreadsheet again...It would be much better if spreadsheets would be directly queried inside zmquerydatasets, without intermediate exporting to csv...
So, I see two possible major goals to achieve:
A) to provide pure in-memory relational SQL database, where memory datasets are queried inside JanSQL, rather then querying corresponding csv files.
B) "MS Access"/"MS Excel" hybride - a package that defines database as folder containing spreadsheets, spreadsheets are treated as spreadsheets but can be additionaly SQL queried, where resultset can be saved as new spreadsheet. This is already possible, but with unnecceessary step involving exporting spreadsheets to corresponding csv files.
I'm particulary excited with the latter idea. Imagine Excel providing SQL capabilities!