> I did so and It returned error messages for:
> PRNSETUP 'printername'
> LAUNCH
The thing you have to remember with Triggers is that they run WHENEVER the
trigger is fired, whether that is in R:Base, Oterro, or whatever. Remember
that Oterro is generally used to drive web servers. So imagine your copy of
Oterro is running on a WinNT web server in some locked room in Los Angeles,
and the user is running in a browser on a Macintosh in Ulan Bator, Mongolia.
The user pushes a button that updates a row in the database. That fires a
trigger which tries to execute the PRNTSETUP command on THE COMPUTER RUNNING
OTERRO. Now, the printer setup dialog appears on the server in the locked
room in LA, and the whole application stops, waiting for someone to hit the
OK button. No Good!
Similarly, if the Launch command where allowed in Oterro and your
application included some kind of ability for the user to enter SQL commands
and have them passed to the back end, then the user would be able to run any
command ON THE SERVER. A bad security violation.
Similarly, the commands:
> It did not return error messages for:
> OUTPUT xxxx.reg
> OUTPUT xxx.BAT
> OUTPUT PRINTER
> OUTPUT SCREEN
> ZIP
could all be used to crash the server (by output over a necessary system
file, spooling enough output to fill the hard disk, etc).
> This would be a very powerful technique where using a table trigger, an R
Base
> reports to a PDF file can be generated automatically.
Personally, I would worry about leaving an unattended computer doing things
like generating PDFs on its own. How about the following:
1. Use the trigger to write a record into a table noting that a report is
needed.
2. On a separate computer (could be the server, but I'd think twice about
that setup) periodically kick off a routine that runs a full copy of R:Base,
generating whatever report you need.
--
Larry
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
