|
> -----Original Message----- > From: Steve Richter > > Consider the administration work needed when using db2/400 as a > true server: This is not a "true server". This is a remote database, the most difficult of all architectures to administer, and one which should be avoided, since it ties all tiers of the application to the physical layout of the database. > installing client access on the remote pc > creating user profiles on the 400, scheduling password chgs > managing client access updates and password changes > troubleshooting the ddm over tcp/ip server jobs and connection errors > Work and research needed to address performance and compatibility > issues. I know I harp on this all the time, but a message-based client/server approach will eliminate most of these problems. With a browser-based UI, you're talking about nothing more than keeping your LAN running. > If you are using db2/400 as a database server, I think one or > more dba's are > needed. If you are using a remote database, you're ASKING for a lot of additional work. That's why it's perhaps not the most cost effective solution. Joe Pluta www.plutabrothers.com
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.