> Why not use IBPERL or java or something on the server side? There are a
> lot great middleware solutions available. I suppose IB can be modified to
> call out to an external exe or something but this would have to be done
> carefully it's a huge security risk.

I do this alot with server side bots that listen to events and perform
certain actions for the client, but, this is not a solution for all
needs. Very often you need alot of processing to be performed on
records during insert/updates/deletes that need to occur as the
operation is taking place. An outside application does not serve well
in this instance.

As for spawning a outside program to call back into the database on it's
own connection/transaction so it can not see what you are currently
doing until you commit your work....too many complex interactions to
worry about.

Also, IBPerl, java, Delphi, FPK, C, all the rest, require a complete
program to operate, with SP code, you are only adding a small (probly
under 10 lines) piece of code that is easy for a end user to understand
and /or manipulate.

Programs in a company are not static, they are constantly changing as
the business changes. You need to keep a single simple standard for
cost effectivness. The current database at distributel has changed
dramatically from it's origional design, but, we have SP code that has
been there from the beggining and other code that is just a few hours
old.

> I think a robust language for stored procedures and udfs is a great thing
> but you have to draw the line someplace sooner or later. It seems to me
> it's better to take the Postgres approach and make it a pluggable thing.
> Take an open source language, make slight mods to it to get rid of the
> potentially dangerous things and plug it into the database.

I don't care really what the server side language is, as long as it
gives the same or better functionality. Do it as a plug-in or just keep
the current code and add to it.
I would prefer to keep the current SP language as it is simple,
straightforward and easy to maintain. It would be far less work to add
one or two things to it then to try to totally rewrite the calling
mechanism so a plugin system would work. You also have to consider
legacy code, switching to (insert language of choice) as the embedded
language would make the switchover very difficult for those who do not
know (language of choice).
Since SP code is a very simple extension to SQL code, and this is a SQL
database, it makes sense to keep it the way it is.

Just my 2c worth

Dalton