RE: Occasional .Net InvalidCastExceptionfromw/inMapSQLTypeToiDB2DbType

Actually, MPhostcolInfo(1) is enough since Prepare() continues to fill
it after returning from createSQLForiServer....

So either the fault is somewhere in Prepare()/DeriveParameters() or the
GUID (if it's a System.GUID type) is invalid, maybe.

Good way would be to trace everything with Reflection.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of ibm
Sent: Monday, September 21, 2009 12:01 PM
To: Midrange Systems Technical Discussion
Subject: RE: Occasional .Net
InvalidCastExceptionfromw/inMapSQLTypeToiDB2DbType

Walden,

The constructor for iDB2Command(iDB2Connection) is what you are invoking
by calling cn.CreateCommand(). This ctor sets m_preparedSqlStmt =
string.Empty. Then DeriveParameters calls Prepare since
this.m_preparedSQLStmt.Length == 0. This fills this.m_paramColInfo,
therefore != null. Looking at the parameter identification code in
createSQLForiSeries, using @param instead of ? sets flag2 = true which
triggers a more comprehensive parameter collection building process.

Hmm,,, it looks like the use of ? as param markers never sets flag2 =
true which stops the internal parameter collection creation at
this.m_paramColInfo = new MPHostColInfo(colCount); within
createSQLforiSeries...

What do you think?


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Monday, September 21, 2009 10:46 AM
To: Midrange Systems Technical Discussion
Subject: RE: Occasional .Net InvalidCastException
fromw/inMapSQLTypeToiDB2DbType

Chris,

Saw that in reflector. I guess I could also turn on trace as it will
show the value that couldn't be translated, but it's odd that this runs
for weeks w/out a problem. I may end up tracing it, but it would end up
being a huge trace file I think.

We're not explicitly setting the parm type, it's being inferred (and is
a string) as follows:

DataRow dr = Data.ExecuteDataRow(
"SELECT Loan, CSRUserId, namefornewcard FROM PaymentRequest
WHERE PaymentRequestGuid = ?",
CommandType.Text,
paymentRequestGuid.ToString().ToUpper());


And inside ExecuteDataRow is:

using (iDB2Connection cn = GetConnection())
{
iDB2Command cm = cn.CreateCommand();
cm.CommandText = commandText;
cm.CommandType = commandType;
cn.Open();
if (log.IsDebugEnabled) {
log.DebugFormat("Job: {0}", cn.JobName);
log.DebugFormat("Library list: {0}", cn.LibraryList);
log.DebugFormat("Options library: {0}", cn.QueryOptionsFileLibrary);
}

//Got parameters?
if (null != parameters) {
cm.DeriveParameters();
for (int i = 0; i < parameters.Length; i++)
cm.Parameters[i].Value = parameters[i];
}

iDB2DataAdapter da = new iDB2DataAdapter(cm);
da.Fill(ds);
}


Look at the stack trace, it's blowing on the DeriveParameter call. Seems
like i5/OS is returning invalid data. The PaymentRequestGuid is a
char(36) on the i. And we can go through this same code 1000s of times
w/out a problem and then it just screws up.

-Walden