Hi Thorbjørn,
You still need the ODBC driver. The JDBC driver is special because...
I'm not particularly interested in defending Microsoft technology, but
I'm not sure I get your point, other than I would agree that Java/JDBC is a
superior solution. You still need a JDBC driver as well. Do you commonly
make code changes to the JDBC driver, or is that really a code term for
"free"? There are other ODBC drivers available in addition to the one with
Client Access.
As to building the table on the AS/400, then using the ODBC driver with
SQL Server to copy the table to SQL Server for performance reasons:
Is this the fault of the database driver, the network or the database
itself?
None of the above. Sorry for not communicating more clearly. The
bugaboo was that the client had ended up with a system that had part of the
data on the AS/400 and the other part on SQL Server. The real solution was
to put everything in one database, but I didn't have that option, and had to
integrate with the existing system and schema. Doing distributed queries
with joins to multiple tables *in different databases* ( "different" here
meaning not just on another computer, but also on a completely different
DBMS ) was too expensive in terms of processing, regardless of which
database was the host.
Because downstream processing eventually depended on data resident on
SQL Server, I moved the table from the AS/400/DB2 to SQL Server. However,
the initial data all came from the AS/400. I could get it built from SQL
Server by using the AS/400 ODBC driver with a distributed call. However, it
turned out to be far faster to continue building the table on the AS/400 and
then let SQL Server use ODBC for a copy of the single table.
Joe Sam
Joe Sam Shirah -
http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum:
http://www.ibm.com/developerworks/java/
Just the JDBC FAQs:
http://www.jguru.com/faq/JDBC
Going International?
http://www.jguru.com/faq/I18N
Que Java400?
http://www.jguru.com/faq/Java400
----- Original Message -----
From: "Thorbjoern Ravn Andersen" <ravn@xxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Thursday, October 29, 2009 12:11 PM
Subject: Re: Retrieving integer parameter after JT400 ProgramCall?
Joe Sam Shirah skrev:
Hi Thorbjørn,
Having it work with JDBC means that it will work with any language that
can talk to the database and not only Java.
I assume you really mean the SQL portion. The Java JDBC portion is
not
going to work with another language without conversions, etc. as with any
other multi-language app.
Yes, I mean the "carry SQL command with parameters to database, and
return result to caller" technology which is named JDBC in the Java
world, ODBC in the WIndows world (if it hasn't been replaced with
something else).
Is there any other database connector which can be carried around like
jt400/jtopen or do they all require Client Access installed?
ODBC, although you need a language that understands ODBC - Java's ODBC
bridge has never been recommended for production quality applications..
As
an example of something that seems inefficient on the face of it, in my
last
project, we had to get a table with AS/400 data to a SQL Server database.
SQL Server will actually do distributed queries with minor setup, so we
dumped the AS/400 ODBC driver in SQL Server.
You still need the ODBC driver. The JDBC driver is special because it
is 1) open source and 2) does not require some IBM product to be
installed on the host. I am doing a simple project where this is an
important parameter as it allows us to do web start clients to casual
users hence the interest as we have several .NET-clients who would like
us to cater to some of their needs.
In a case similar to Samuel Johnson's dancing dog, it's amazing that
it
will do it, but it's dog (a pun - serendipity) slow - understandable;
think
what it has to do for joins. So, we built the table on the AS/400, then
copied to SQL Server using the ODBC driver (still called from Java.) The
time went from literally about 5 minutes to about 10 seconds. Since the
process is interactive, the more than an order of magnitude improvement
made
the difference between the app being usable and just another dead horse.
I do not know of Samuel Johnsons dancing dog, so this analogy is a bit
lost on me. If I understand you correctly, you simply build one place,
and move the data elsewhere to make it faster? Is this the fault of the
database driver, the network or the database itself? Or is the benefit
of running the database on the same hardware as the application so big
that the DB2/400 could not compete?
midrange.com
