RE: RPG.NET

> 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