help-glpk
[Top][All Lists]
Advanced

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

[Help-glpk] Error when using "table"


From: Meketon, Marc
Subject: [Help-glpk] Error when using "table"
Date: Mon, 14 Feb 2011 13:04:17 -0600

I've been building a model using GUSEK for the IDE, which seems to use GLPK 4.44.
 
From time to time, when writing out to an Access table using the "table" feature, I get a message from Windows saying "GLPSOL.EXE has stopped working"
 
GUSEK then reports an "Exit code: -1073740940".
 
I have 3 "table" statements, all of them writing to the same database table.  In the first "table" statement, I have 2 SQL statements:  a "DELETE FROM tbl;" followed by an "INSERT INTO tbl" type statement.  In the second and third "table" statement, I have only one SQL statement, an "INSERT INTO" type.
 
When I change the first "table" command to output to CSV file, the output looks fine.  And the other two "table" statements work fine.  Then I change the first "table" statement back to using ODBC, and suddenly it works - at least for the next 10 times I run it.  But then it stops working, and doesn't work again till I repeat the "CSV" trick.
 
Question 1:  I suspect that there is a timing issue with having two SQL statements - that Access hadn't released the table yet after the DELETE FROM statement before it tried to do the INSERT INTO.  Is that possible?  Is there anything I can do about it.
 
Question 2:  Just to play it safe, I tried to create a fourth "table" statement with the DELETE FROM sql in it, and run that first at the beginning.  Except that it does not work.  Specifically I tried (after finding something that syntactically works):
 
    table result2 {x in EMPTY_TYPES : x=""} # this is the null set, no string in EMPTY_TYPES is blank
        OUT 'ODBC'
      'Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=' & DB_LOCATION & ';'
      'DELETE FROM fc_ForecastEmpties;' : 1~ID;
 
But it did not delete the records, and the GLPSOL output says:
 
    Writing result2...
    Connected to ACCESS 04.00.0000 - C:\Forecast.mdb
    INSERT INTO DELETE FROM tbl_result; ( ID ) VALUES ( ? )
 
So by not having an INSERT INTO statement, it looks like the "table" statement put one in automatically, and in an unexpected place.



This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.

reply via email to

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