Re: [Bug-glpk] Assertion failed: str2num(buf, &num) == 0 Error detected in file ..\src\glpsql.c at line 900

[Noli Sicad]

Hello Xypron,

I recompiled glpsol with the new patched glpsql.c, it still not solve
the problem. I still the same error.

I sent you a copy of this mdb - Otago.mdb (Otago.rar) the other day.
Did you get it. Please have a look at the query "qryCrorptype". It
seems that this table produce by query has a lot of "blank" data in
the rows.

~~~~~~~~~
printf "Reading Croptypes....\n";
table tblCroptype IN "ODBC"
    'DSN=Otago_mdb'
    'SELECT * FROM qryCroptype':
        CROPTYPE <- [Croptype], CroptypeOrigin ~ Origin, CroptypeSpecies ~
Species, Value, Rental, Share, Flat, FlatRolling, RollingSteep, Steep,
OpType;

~~~~~~~~~~~




GLPSOL: GLPK LP/MIP Solver, v4.42
Parameter(s) specified in the command line:
 --cover --clique --gomory --mir -m OtagowithEstate2_mdb.mod
Reading model section from OtagowithEstate2_mdb.mod...
OtagowithEstate2_mdb.mod:75: warning: keyword within understood as in
OtagowithEstate2_mdb.mod:324: warning: unexpected end of file; missing
end statement inserted
324 lines were read
Reading tblSpecies...
Connected to ACCESS 04.00.0000 - C:\FORESTRYLP\Otago
SELECT * FROM tblSpecies
Display statement at line 176
SPECIES:
   '???'
   FIR
   OTH
   RAD
MinCFAge['???'] = 1
MinCFAge[FIR] = 36
MinCFAge[OTH] = 20
MinCFAge[RAD] = 27
MaxCFAge['???'] = 60
MaxCFAge[FIR] = 70
MaxCFAge[OTH] = 70
MaxCFAge[RAD] = 70
Reading tblOrigin...
Connected to ACCESS 04.00.0000 - C:\FORESTRYLP\Otago
SELECT * FROM tblOrigin
Display statement at line 182
ORIGIN:
   '??'
   Otago
   Southland
Reading Croptypes....
Reading tblCroptype...
Connected to ACCESS 04.00.0000 - C:\FORESTRYLP\Otago
SELECT * FROM qryCroptype
Assertion failed: str2num(buf, &num) == 0
Error detected in file ..\src\glpsql.c at line 900
>Exit code: 1073741845    Time: 2.605


On 2/16/10, Xypron <address@hidden> wrote:
> Hello Andrew,
>
> please, find a patched glpsql.c appended.
>
> The diff can be seen at
> http://glpk.dyndns.org/viewvc/svn/glpk/branches/glpk-4.42-sql_null_data/src/glpsql.c?view=diff&r1=85&r2=83&diff_format=h
>
> Best regards
>
> Xypron
>
>
> Andrew Makhorin wrote:
>>>> Andrew, do you have any suggestion how to patch this bug properly?
>>>>
>>> Consider the following example:
>>>
>>>     table data IN "...": s<- [FROM,TO], d~DISTANCE, c~COST;
>>>
>>> For fields FROM and TO a null value is not allowed and should cause
>>> an error. However, for fields DISTANCE and/or COST it could be allowed,
>>> that would mean missing data.
>>>
>> I think that if the table driver routine encounters a null value, it
>> would be sufficient just *not* to call mpl_tab_set_num/str, in which
>> case dca->type[k] being initialized to '?' will not be changed and cause
>> an error.
>>
>>
>>
>
>