Maybe it's by design, but the SQLitening.txt file doesn't mention anything about such a restriction. I was trying to use CHR$(0) as the record delimeter.
It wasn't by design, it was by mistake/oversight. I determine the values
following the Q ModChar and then if they are zero I assumed you wanted the
defaults. Never even thought about you may want to delimit with Chr$(0).
I will either fix the code or the documentation in next release. For now
Chr$(0) can't be a delimiter. Thanks for letting me know.
I was hoping to try an optimization using ASCIIZ PTRs to process the returned data. It seems that fetching a record at a time (when processing multiple columns & rows) is actually faster than processing slSelStr results with nested PARSE statements and that just seemed counter-intuitive to me.
slSel with multiple slGetRow commands will always be the faster way to do
forward only queries.
If you need the ability to go backwards in your record set then using
slSelAry would probably be the preferred method. Builds the array by
doing a slSel followed by all of the multiple slGetRow commands.
If the amount of data is small then slSelStr may result in the easiest to
code but will always be the slowest. Build the returning string by doing
a slSelAry and then converting the array to a sting using the Join$