On Fri, 4 May 2001, Joel Burton wrote:
> On Fri, 4 May 2001, Stephan Szabo wrote:
>
> > > Can this be done? Is this terrible design? Is there any other reasonable
> > > way to handle things like this?
> >
> > Probably could be done, but the question would be what happens if the
> > TRANSACTION_AFTER raises an error condition for whatever reason? You
> > can't go back and un-commit the transaction.
> >
> > For that case above, you'd probably be better off having something in cron
> > or whatever looking at your email-to-send table since it'll get only those
> > things that have already committed. You could put all the logic in a
> > function on the server still.
>
> Yep, you wouldn't be able to raise a meaningful error at this point.
> Comes with the territory.
The problem is that you have the problem in reverse then, unless what's
done by the trigger is "optional" sortof. What happens if there is an
error, and you can't do the outside operation? You once again end up
out of sync with the database, but this time the outside thing is missing
the records. You still need something to come in every so often and make
sure stuff is correct.
This whole class of things is just ugly.
