Re: ODBC was: Trigger programme without a trigger.

<snip>
the most important being that I can't ensure that the validation will be
done
</snip>

But couldn't you? With the server based I/O module approach you basically
- secure the file out from all users except for some user profile reserved
for program adoption
- Set up your I/O module program as owned by that user profile
With the client based I/O module you
- secure the file out from all users except for some user profile reserved
for this
- Tightly control that user id and password to be buried in code somewhere
so that only that one ODBC process can update the data.
I am not saying unfettered ODBC updates anymore than I am saying
unfettered "traditional" updates.
Now, if you, or someone you trust, has written the ODBC process does that
necessarily make it any less protective of the data integrity than a
server based program? I'd argue that the difference shouldn't be any less
between a server based and the client based, than a server based program
written in COBOL versus a server based program written in RPG.

Rob Berendt