Regarding using "$gettok hacks" to deal with many "columns" of data... first of all, if you have 70+ "columns" per item, you really should consider a better storage method as that's not very efficient. Second, using /tokenize may save you some headaches depending what you're doing.
I was going to suggest the same thing, and regex searching hash table data would easily allow you to search in a specific 'column'. As far as 70+ columns are concerned, its not a matter of the storage method being inefficient, it is completely down to the database designers inability to design efficient table and database structures. If you have a table like that you should grab a reference book or consult online manuals and learn to do it properly.
Perhaps as a portability option, instead of tying ONE sql engine in, an ODBC or similar handle could be used, thus allowing the use of any external data source.
I have never specifically done anything utilising 'ODBC' myself in the past, but this is certain a much more useful suggestion imo. I guess this would be sort of what i was refering to with the mention of 'generic interface' much further up.
...that all tests are done with files all containing the same info...
But is your database/table defined in the same way the ini file is, eg create database ini_files; create table ini_file { section_item varchar(), data varchar() }; insert into ini_file (section_item,data) values('SECTIONNAME_ITEMNAME','DATA');
In order to accurately compare the engines/methods themself you need to mimic the format in which the data is stored. And when testing this way you MUST include the time taken for the mirc script to process as well (ie, SECTIONNAME $+ _ $+ ITEM, to compile the query). I am by no means claiming that sql wont be faster, just that perhapse your results are likely inaccurate because your probably comparing in such a way that relates to measuring how long it takes to write the letter I or the letter M.
Sure dll's are nice and all that, but built in functionality is always better, and being paranoid as I am, I'd trust Khaled over some random person that made the dll, even if I know neither of them personally, Khaled would have the reputation and the fact taht he's releasing a thousand, maybe half-million user program, unlike the dll guy that has no given numbers beforehand, and so releasing a virus/trojan (if there was one) wouldn't be as noticed.
One problem with Khaled writing his own functions to interact with SQLite is the fact that those function would be completely dependant on the version of sqlite availible at the time, changes to sqlite could render it unusable until a new mirc version is released with updated functions in mirc.
Somebody mentioned about adding support in the manner that SSL is done, where identifiers are availible if the dll is preset. This pretty much servs no purpose imo, because other than a few bytes less code (replaced with code in mirc instead) whats the difference between using $sql(args) and $dll(sql.dll, args).
