I agree that 100 characters is probably reasonable for variable names
and other uses of the strings. However, for the table statement it is
much too short. It appears that there are two remedial actions possible:
1) change the limit for every data structure to say 2048, advantage is
the simplicity of change but wasteful for most uses of the data structure
2) introduce a new data structure and limit for the table string only,
size 2048. Efficient in memory but all the coding with respect to
parsing and error reporting then has to be adapted for the two data
structures.
While neither method is perfect, approach 1 seems much simpler to
execute. Just leaving 100 characters for an SQL query is not usable in
practice. What is the memory penalty for the first method?
Marc Goetschalckx
On 18-Feb-12 5:27 AM, Andrew Makhorin wrote:
Hello,
The model is writing back solution values through odbc (Windows) when
the error "literal string too long" is generated in parsing the TABLE
statement. Other table statements in the model to read and write work fine.
I have shortened all names as much as possible, but this is a relatively
complex SQL query that cannot be split, i.e. it is for a single SET
operation. Is there a workaround for this error?
Please see the topic "100 character limitation" in the article
http://en.wikibooks.org/wiki/GLPK/ODBC
How large is the string limit.
Currently the limit is 100 chars.
How can it be increased.
I also suggest that in the next release of GLPK the limit is increase to
a few thousand of characters, say 2500. Current main memory is measured
in the gigabytes, a few k for SQL queries is acceptable.
Initially, on development of the mathprog translator, symbolic values
(i.e. character strings) were intended only to be used as elements of
indexed sets, so the limit of 100 chars seemed sufficient (the table
statement was implemented later). The problem is that to increase this
limit many data structures should be changed, though using long strings
is really needed only in the table statements.
Andrew Makhorin
--
Marc Goetschalckx
Industrial and Systems Engineering
Georgia Institute of Technology, Atlanta, GA, USA
_______________________________________________
Help-glpk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-glpk
