Tweet
I need a way for a Windows 95 PC application, like VisualBasic or Access, to write and read directly to and from an AS/400 database. The AS/400 essentially becomes a file server to the PC application. I'm sure this connection can be made in a seamless fashion, but I need some advice on how to do it.
-
-
PC to AS/400 Database Connection
There are three fundamental ways to do this:- ODBC - Using the ODBC dirver that comes with CA/400 is easy to use, but performance can be a problem.
- Data Queues - This is conjunction with APPC APIs communicates with a running AS/400 program to update your data.
- OLE using ADO - The best performance, but the hardest to use. CA/400 comes with a VB SDK that helps.
-
PC to AS/400 Database Connection
I'm taking the plunge with ODBC and Client Access. I'm developing the applications that use the data mostly in MS Access. But, there are RPG applications using the files, as well. My goal in this: replace and centralize the many awkward, bloated and impractical Excel workbooks trying to do the jobs of databases, scattered all over the organization: redundant, inaccurate and requiring the data be keyed, rekeyed, and then keyed in again! So far, I'm liking it a lot. ODBC is easy to get set up (security is a concern with any of these, by the way), once you get the hang of it. In fact all new tables I develop for the MS Access applications are being defined and served up from the AS/400. It's our only SQL server. I tried leaving non-legacy files in Access tables on the NT server, but the performance was just appalling once we got into multi-user reality. Performance improved vastly when I moved all the tables up to the AS/400! I learned some other performance tricks, some right here on the MC Forums. For one, don't use underscores in your file names unless you precede them with a backslash (the default names for tables linked via ODBC includes an underscore between the library and file name, get rid of it!). I believe underscores in field names to be a very bad idea as well. Has something to do with SQL interpreting that as a wildcard character, I think Keep your Access queries clean and simple; don't take more fields from legacy files than you'll use (i.e. build an Access query that doesn't bother with fields you're not using in your Access database). Don't use functions in your immediate queries and SQL statements that aren't supported on the SQL server. Otherwise, work has to be shifted from the optimized SQL server down to the little PC you're using. Good luck! It would be great to hear about your further adventures, like what you chose, and how it's going, and details. Thanks!Comment
-
PC to AS/400 Database Connection
Hi Wesley, In addition to the other suggestions, there is also java and JDBC. All of these can suffer, however, in that individual database connections are opened for each program, performance can suffer, and, other than some types of java apps, often require both drivers and setup on client machines. Other possibilities are server type programs. In this category, sockets or some other type of connection is used and a request is made to the server program, which accesses the data. This minimizes remote database connections and allows the server to optimize in any way it sees fit, even using "legacy" programs. The server could be in almost any language, although thread supports helps. Another possibility in the same category is java servlets; as normally used, they are based on HTTP, but generic servlets can also be written. Again, what actually happens on the server side is up to the server program. This type of processing can also eliminate some of the serious security concerns with using ODBC directly. Notice that this type of processing means that server or client side programs can be modified or completely exchanged without affecting the other, so long as the protocol is adhered to. Also, this type of processing can later be extended to, for example, WANs and the internet. Joe Sam Joe Sam Shirah Autumn Software Consulting/Development/Outsourcing Please Note New Email: jshirah@attglobal.net Visit our User Group at: http://www.jax400.comComment
Comment