Jim Starkey wrote:

>I disagree strongly. Having the database schedule tasks from a known
>account is extremely powerful. It is also platform independent, unlike
>cron. It also avoid any problems related to embedding passwords in
>command files.
>
>
>

I must agree and disagree with you.

I agree because if a feature is implemented and someone doesn't care
about it it could simply ignore it, and I agree because embedding some
admin tasks into the database could lead to easy setup and migration
procedures.

But I disagree since it is already available (ok, with dependencies in
3rd party utils) and the time/effort needed to implement something a
"bit" better that what we already have could be spent in another feature.

I don't object to have it inside the engine but what will be the
priority ? What do FB developers has in the todo list that has a hight
priority ? How dificult will be ?

>Surely you would concede that shipping the database with a procedure
>that could backup the database on a regular schedule would be a
>wonderful thing that any sane DBA would love.
>
>

As I understand it will be a scheduler to run Stored Procedures, so we
will have a SQL command to do backups ?

The current approach I have with backups are:
1.) Do the back-up
2.) Restore it to some other place (the only way to be sure the back-up
file are ok and without logical corruption)
3.) Zip it and ftp it to some other place
4.) Delete all the garbage (back-up file/ teste restored database)

With Java Stored Procedures the things will be really interesting, but
with the current PSQL no way to send e-mail, no way to interact with non
FB objects (files, system logs, ftp and so on). I think UDF's are not
the correct way to implement such features.

The script executed will be a Stored Procedure or a "Execute Block" ?

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br