• Welcome, Guest. Please login.
 
August 19, 2019, 07:23:43 am

News:

Welcome to the SQLitening support forums!


"Q.0" modchar for slSelStr does not work

Started by Bern Ertl, January 12, 2011, 04:19:12 pm

Previous topic - Next topic

Bern Ertl

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.

Fred Meier

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.

Bern Ertl

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.

Fred Meier

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$
command.