|
> It's clear to me that you haven't really designed one of these systems. And when I said this, it wasn't meant to imply that you haven't designed and implemented complex systems, Walden. It's just that you seem to be shooting from the hip in your answers to what I consider basic questions of systems design for complex applications. The issues of multiple-record edits, atomic and subatomic error checking, multi-file incidental updates, locking and synchronization, all of these are better served by a client/server protocol. The XML approach you mentioned is a little closer to the mark, and done properly it is in effect a message based protocol. At that point, though, ODBC is now entirely out of the question, and you're doing true messaging. And once you get past the basics of the architectural requirements, then you move on into issues of performance. At that point, you start getting into stateful servers and that's far beyond the capability of a pure ODBC approach. Anyway, I realize the statement might have sounded condescending. It wasn't meant to be so. It's just that you seem to be making light of architectural design issues that have been in place for a long time. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.