×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 02 Apr 2013 15:15, Jim It wrote:
Ok, I thought I'd let everyone know, I got an answer from IBM. Not
exactly one I like, but it is a work around.
The connection property - "metadata source" Specifies how to
retrieve DatabaseMetaData. If set to "0", database metadata will be
retrieved through the ROI (Retrieve Object Information) data flow.
If set to "1", database metadata will be retrieved by calling
system stored procedures.
Defaults: "0" (V6R1 and earlier) "1" (post V6R1)
So, the answer is to set the connection for v7r1 partitions to
"metadata source" = "0" and do it the old way.
An answer or a circumvention [i.e. work around] until the issue is
corrected? There is nothing about the enhancement that suggests a loss
of function should be expected; i.e. "compatibility" does not imply an
ability to achieve the /correct/ results, rather the equivalent results
as those in the past. If the REMARKS are correctly the NULL value
because there has been no COMMENT ON established for those columns, and
the enhancement /properly/ gives LONG_COMMENT instead of LABEL details,
that would seem to imply that the old method gave the wrong results and
the /compatibility/ is the ability to get the wrong results.?
As suggested in my prior reply... Was the SQL catalog reviewed for
the information to determine if that is correct or incorrect in the same
manner as the retrieved metadata using the /stored procedures/ method vs
when using the QZDAROI? And for the results for a duplicate of the
file? Review of that information could help understand if there is a
defect... irrespective of what either may have been implied or what
might have been implemented as a /work around/ of the issue.
Well... whatever... I suppose given the issue is likely perceived as
resolved, the above commentary was pointless.
So For anyone else, and the archives, here is documentation about the
change:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzahh/rzahhjdbcenhance71.htm
IBM i 7.1 Information Center -> Programming -> Java -> IBM Toolbox for
Java -> JDBC
_i Enhancements to IBM Toolbox for Java JDBC support for IBM i 7.1 i_
"...
_i Database metadata updates i_
Database metadata is obtained by calling the various methods of the
AS400JDBCDatabaseMetaData class. Starting with IBM i 7.1, the default
behavior of IBM Toolbox for Java JDBC is to obtain this metadata from a
set of standard system stored procedures. This brings IBM Toolbox for
Java into alignment with IBM i native JDBC support in addition to JDBC
drivers on other platforms. Prior to IBM i 7.1, IBM Toolbox for Java
obtained the metadata from the host servers ROI data server. This
approach has worked well, and has also kept IBM Toolbox for Java in
alignment with ODBC, .net, and other IBM i clients. The problem with
this approach though, is that across IBM, all JDBC DB2® drivers should
function the same way. This can be achieved by using a set of system
stored procedures that are common across all of the DB2 platforms. These
system stored procedures are called to obtain system database metadata.
In order to provide backwards compatibility of the metadata
functionality, a new connection property, "metadata source", can be used
to force IBM Toolbox for Java JDBC to use the old method of retrieval of
database metadata.
..."
midrange.com
