Fabricio Araujo wrote:

>>From my POV the concept of backing up a database doesn't really need to
>be done on database *context* (one that each SQL must be inside a tran-
>saction) but on a server context. So:
>BACKUP DATABASE A:db1 to db1_23042005_2305.fbk
>RESTORE DATABASE A:db2 FROM db2_23042005_2305.fbk
>etc (these are just examples)
>
>will run on a server context... Since these are transaction-less SQL
>extensions
>why complicate the thing dispatching it from a db context?
>Same to CREATE DATABASE. No need to be parsed at client library, just
>send it to
>the SERVER. If it's on the wrong context, give a error message.
>
>

Your issue isn't the database context, it's the context for the external
backup file. You want a server context because you don't have any other
way to specify where the backup is to take place. I don't think your
proposed solution helps. To my eye, the statement

BACKUP DATABASE A:db1 to db1_23042005_2305.fbk


means back up the database to the file "db1_23042005_2305.fbk" on your
server. And if you ran gbak with the command line:

gbak -b A:db1 db1_23042005_2305.fbk

that's exactly what it would do. What you're saying is that you want
the system to deduce that you want the backup operation as well as the
backup file to execute on the same node as the database.

I think that the domain of the SQL language should be the database, no
more, no less. Things that aren't visible in the database shouldn't be
manipulated through SQL. You can declare UDFs and external files in
sort-of SQL, but you can't create either. This principle extends to
backup files. A backup file isn't visible to the database, it isn't
described in the metadata, so the language to create it should be part
of the database access language.

I'd like to go further and say that any database operation that creates
objects outside of an existing database file should require an explicit
site password, and that the site password not be settable from within
the database context, i.e. it must be set at command level by a OS
privileged person.




--

Jim Starkey
Netfrastructure, Inc.
978 526-1376