Re: Trigger programme without a trigger.

Granted my post was a bit negative.

No further sarcasm below.

However, if one is ultra serious about I/O modules then why would one use
"external" definitions on their files and not the structures that S/36
(and before) people had to use? After all, if only one I/O module has
access to it, then using no external definitions is further assistance to
"security by obscurity" and further encouragement to use the I/O module.
You've stripped off the use of constraints, referential integrity,
journals, triggers, (and a lot of people - real date fields) why not strip
off external definitions also? It's not like the other programmers should
ever use data structures in their programs based off of the file to define
their local variables, because, with external modules, the size of
variables could change, etc.
Let's take this further, why be concerned with field encryption? If the
whole record is nothing but one big field you can encrypt the whole record
and really confuse anyone who tries to access the table outside of the I/O
module. Let them try to determine field boundaries on that puppy!

Some may argue that going back to no external definitions will send them
off to ga-ga land, especially if they just "nativized" their last S/36
customer. My argument is leaving their files without constraints,
referential integrity, journals, triggers and real date fields sends me
off to ga-ga land.

Rob Berendt