× 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.



I'll throw my hat in the ring here. I've used a couple of these.

RDO (you didn't list this) is a layer on top of ODBC that avoids the jet
engine of VB. Jet is about the worst option, as it goes to the least common
denominator. Take a look at the Client Access ODBC Drive manual from a few
releases ago - is it available in more recent release? It's excellent.

ADO is a thin layer on top of OLE/DB, for ease of use.

You could write to both APIs and get a little better performance
(difference greater with RDO vs. ODBC)

NetServer is for entire files only - no record-level access.

Performance with ODBC and OLE/DB is completely dependent on good use of
indexes, so turn on STRDBG in the serving job QZDASOINIT. V5R1 version of
ODBC driver lets you turn this on from the data source definition. Then you
can get index recommendations. You CAN get excellent response from ODBC
with good indexes and larger block sizes, etc. Likewise with OLE/DB. Check
the Knowledge Base.

Someone suggested stored procedures. Excellent approach - let the hard
database work take place on the server, then deliver only what is
absolutely needed.

Sockets could be tough, I think. The details of the sockets interface to
host servers are not generally available - I think you need to be a part of
PartnerWorld to get LIPIs (Licensed Internal Product Interfaces?) Of
course, you could write your own server.

Take a look at Visual Age for RPG - IBM's product - it creates Windows apps
with 'native' record-level data access. It can also generate Java from RPG
code. It comes in Websphere Development Studio Client (newer) or Websphere
Development Tools (older)

Net.data may be an option, too, but only for web pages.

At 03:15 PM 8/12/02 -0500, you wrote:
>I'm not sure how I will access the iSeries data.  I know that ODBC is
>probably the least efficient of all approaches, but it is also the common
>denominator for access to many databases.
>
>I would like to see reasons for & against the use of each of these
>approaches (ADO, ODBC,OLE/DB, Sockets, NetServer) to access the database.
>
>I am doing some research on how to access the iSeries data directly from a
>VB
>application (sales order entry front-end).
>
>The VB application uses a SQL server 2000 database for its local tables, and
>constructs XML to send/receive data with an EAI application that passes data
>back and forth to the iSeries.  It does not currently have any direct access
>to the iSeries database.
>
>We are looking at various methods of retrieving iSeries data directly for
>display/update.  I'm currently evaluating the DataGate/400 software from
>ASNA, which uses sockets to communicate with the iSeries.
>
>I'm also evaluating the use of ASNA's AVR (Visual RPG) product to build this
>sub-application instead of having to build the functionality in the VB
>application (OR, heaven forbid, using a screen-scraping application like
>JWALK).



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.