JDBC Type 2 Driver Programmer's Reference for SQL/MX Release 3.2.1 (H06.26+, J06.15+)

Known Issues
Scenario 1
MFC plans become obsolete when the base table is altered or dropped. The following sequence
of operations illustrates the issue.
Remarks
Actual
Result
Expected
ResultOperation
Table testing is created.SuccessSuccessCreate table testing(info
int);
Stmt1 is prepared with MXCMP.SuccessSuccessStmt1 = Prepare("select *
from testing")
Stmt1 is executed.SuccessSuccessStmt1.execute()
Data in the table testing is retrieved.SuccessSuccessStmt1.fetch()
Compiled plan is retrieved from MFC.SuccessSuccessStmt1 = Prepare("select *
from testing")
MFC statement works as expected.SuccessSuccessStmt1.execute()
The table testing is dropped.SuccessSuccessStmt1.executeUpdate("drop
table testing")
The table testing is created with varchar column.SuccessSuccessStmt1.executeUpdate("create
table testing(mycol
varchar(10))")
Compiled plan is retrieved from MFC, which is not
correct because the table datatype is changed
when the MFC plan is created.
SuccessSuccessStmt1 = Prepare("select *
from testing")
JDBC T2 driver turned the SQL/MX CQD
recompilation_warnings ON. SQL/MX throws SQL
FailureSuccessStmt1.execute()
exception upon similarity check failure and the
JDBC T2 driver drops the invalid module file from
the location specified using the
compiledmodulelocation property.
A new plan is created in the MFC location.SuccessSuccessStmt1 = Prepare("select *
from testing")
MFC statement works as expected.SuccessSuccessStmt1.execute()
When performing the above operations, the execute() call fails when an invalid module file is
found in the MFC. However, subsequent prepare() calls create a new module file. This issue is
similar to that with driver-side cache present in the JDBC/MX T2 driver.
Troubleshooting MFC 61