ODBC was: Trigger programme without a trigger.

Let's get this straight. There's nothing that says ODBC is any more prone
to hose up your data than unfettered access via more "traditional" methods
of updating. There might even be a business case that the I/O module be
ODBC resident because of some unique requirement. (Don't ask me to name
one, because of SOA, sockets, external JDBC access, etc, most of this can
be done "native" now. But something in the genre perhaps.) And, it may
be advantageous to write the I/O module on the ODBC client because all I/O
is expected to come that way any (Like a migration from an i based EDI
package to an x based EDI package.) so why burn up the bandwidth and
processor on the i when the error checking can be done on the dedicated
processor on that x?

Rob Berendt