[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Error literal string too long in TABLE statement

From: Marc Goetschalckx
Subject: Re: [Help-glpk] Error literal string too long in TABLE statement
Date: Mon, 20 Feb 2012 09:51:14 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100216 Thunderbird/3.0.2

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:

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]