Re: ODBC was: Trigger programme without a trigger.

rob@xxxxxxxxx wrote:

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.

Yes there is. It's not on my machine. I will not allow ODBC updates to production data. Now, this is a purely personal decision, but I am adamant about it. You want Windows machines updating your database? Fine, that's your call. But not in my shop.

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?

You've just gone from (in my opinion) bad practice to insanity. To delegate business rules processing to a machine other than the i is something I would never allow.

If the two machines are both i's, then there is some leeway. But if you're talking about a Unix box or a Windows machine validating the data that goes into my i, then no way. I draw a very definitive line there.

Joe