Follow by Email

Wednesday, June 20, 2012

Invalid Column type : get_internal_type


Sometimes you are so sure that your application running fine on testing server will also work fine on production as both environment have same data and the data in test was actually imported from production so no problem will occur , well life is not that easy for us the software solution providers J.

Today after finishing the requirements from a user in one of my systems and after testing it fully with test data I was going to deploy the application on production environment. Before doing that luckily I tried it with production data and realized it was giving me a wired exception  “Invalid Column type : get_internal_type”.
So again the same application was working fine in test environment which always have the data imported from production , After Googling this exception message we found out that the problem could have been with the data in one of the fields in our resultset.
It was hard to find but thanks to my colleagues Huthaifa,Syed Baqir Ali we were able to find the root cause of this problem which was the problem with the data in “rowid”  in our queries we were selecting the rowid property and it appeared that in JDBC code when we were trying to get the rowid from result set for some records it was giving us this exception and for some it was getting the rowid properly.
We are trying to get the row id by calling toString() method on ResultSet which for the problematic rowids was throwing this exception “Invalid Column type : get_internal_type”.
The only solution is to use the oracle function “rowidtochar to get the row id e.g

Select  a.*, rowidtochar(a.rowid) row_id from student

This way the JDBC code will never throw the exception for this column , now the only reason behind this problem could be rowid generated by oracle sometimes have non-character values and when we try to get the value from Resultset using toString() it can’t parse it to String (However it’s strange how oracle’s own JDBC implementation is not handling this case J , we are using OJDBC6).

No comments:

Post a Comment