|
> -----Original Message----- > From: Brad Jensen > > > This ability to change the underlying physical layout > (including, for > > example, the fact that a file is physically moved to another > machine, or > > even another data format entirely) is the primary reason that a > > message-based architecture is so preferable to ODBC. > > This must be peculiar to IBM's ODBC for the AS/400. It's totally > unfamiliar to me. If you use ODBC and change the name of a column, the ODBC doesn't work. This is the same on any ODBC implementation. You can avoid the issues to some degree on a query you use a "SELECT *", but we've discussed the various reasons why that is bad programming practice. Regardless, to identify JOINs, ORDERs and so on you need to know the column names. The point is: changing column names breaks ODBC calls. > Well ,it seems to me that with programming you can decouple the > data representation at any level you choose. Not if your client relies on knowledge of the table and column names of your database! That's the point of the entire discussion. If the client is dependent upon field names, it is tied to your database, and more importantly, your database is tied to your client. By decoupling the client and the database through an intermediate messaging interface, you thereby remove the dependence of one upon the other, and allow changes to occur in one region that do not affect the other. This is the basic premise behind tiered programming. 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.