I dont think this is the field149 creating the issues. If you remove a few characters in Concat function the script will work. This might be because of any limit on the script function character. I would love to know more on this.
This problem reminds me some of the limitations that we have in the ODAG apps when we try to pass too many values to a variable using LET. I don't know this limit but maybe this ODAG page can help you to find a solution:
This will simplify the approach as well as reducing the length of the string and might therefore uplift the treshold for the number of chars. You could create this structure as well as with a concat-aggregation or maybe also with an interrecord-function within a preceeding load like:
... Temp1: load peek('Values') & Field as Values; load 'Field' & recno() & if(recno() < 149, chr(44)) as Field autogenerate 149;
LET vValues = Peek('Values',-1,'Temp_1');
Str: noconcatenate Load $(vValues) Resident Data; drop tables Data;
This might be the cause and I'm not surprised because there are various similar limitations to the number of (nested) functions. For example within the View release 11 there is a restriction of 99 if-loops within a single expression and also in the current releases of View and Sense are such limitations (maybe the number of them may have changed) intentionally enabled.
AFAIK there is no public documentation about such limitations. Maybe Henric Cronström could shed some light to it.
Running in such limitations is a strong indicator that the used logic has more or less weaknesses and a rethink of the whole task is often better as looking for any ways to bypass it. This means knowing the exact theshold is rather not very useful.
Like in my other answers suggested approach is the creation of real strings probably better and your alternatives to the variable expression-content. Also there might be other (loop) approaches easier to create such strings.
Beside this I could imagine that creating a csv-output of these data which is then imported through your database might be much more convenient as creating load/sql-statements on the fly.