Yes but what you may not see is that if a memory database already exists and you pass the id it will check for it’s existence, so then all it does is replace the table (if it exists) with the name you pass with a new table containing that parsed array. There may be other tables in the memory database, and those are not touched, so theoretically I could pass multiple arrays with different table names, then execute complex queries on those.
In this discussion I can see that there are changes I could make to improve it’s efficiency. I should break out the different operations, like creating the table, querying the database and returning an array as separate functions. The main reason I created this function was because I assumed memory databases would be considerably faster than file based ones, or network based over slow network infrastructures, as well as eliminating the need to create separate handlers for each use case. Bob S On May 20, 2024, at 12:36 PM, Richard Gaskin via use-livecode <use-livecode@lists.runrev.com> wrote: I guess the main advantage for using filterArray() is that using the LC parser, for each use case would require it’s own code. filterArray() is a one-stop-shop approach. For instance, if you need to compare data with another dataset (as in an SQL join) or finding the maximum value in a dataset, or limiting your results. Somewhat. If I read your code correctly, it create a single table from the array, limiting the depth of the array and thereby obviating the complexities inherent in operations across multiple tables. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
