SQL/MX Connectivity Service Manual 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.
RemarksActual ResultExpected 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
SuccessSuccessStmt1 = Prepare("
select * from
testing")
correct because the table
datatype is changed when
the MFC plan is created.
MXOSRVR turned the
SQL/MX CQD
FailureSuccessStmt1.execute()
recompilation_warnings ON.
SQL/MX throws SQL
exception upon similarity
check failure and MXOSRVR
drops the invalid module file
from the
<compiled_module_l
ocation> location.
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 open issue
is similar to the Driver Side Cache (DSC) present in the JDBC/T4 driver.
Module File Caching (MFC) 55