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