Matt,

<< The ideal would be that these could be set per database and by code.
Perhaps a wish for ElevateDB? >>

ElevateDB uses paths also.

--
Tim Young
Elevate Software
www.elevatesoft.com

Robert,

<< I understand that, I just don't think it's right. There is no reason
workstations should have knowledge of "path that is accessible to the server
machine". >>

I disagree.  I think that executing a backup on a remote machine is an admin
task and the user executing the task should definitely know which
destination directory they're putting the backup in (among several other
important pieces of information).  Backups can be very large and
time-consuming, and this is not a normal user function like inserting or
updating rows in a table.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:47098019-BE77-4061-A247-D52CC82F42DD@news.elevatesoft.com...
> Robert,
>
> << I understand that, I just don't think it's right. There is no reason
> workstations should have knowledge of "path that is accessible to the
> server
> machine". >>
>
> I disagree.  I think that executing a backup on a remote machine is an
> admin task and the user executing the task should definitely know which
> destination directory they're putting the backup in (among several other
> important pieces of information).  Backups can be very large and
> time-consuming, and this is not a normal user function like inserting or
> updating rows in a table.
>

Look, the person executing the backup does not "know" anything. It is the
program that "knows". And how does the program find out? It either uses a
database alias (good) or it has a hardcoded path (bad). My only point is
that a C/S DBAdmin system should allow me to login to any terminal as a
"user who can do backups", and perform a backup regardless of this specific
terminal mappings, just by telling the server "backup MyDatabase to
MyDatabaseBackup", and the database system should figure out the mappings.
Also, the IT administrator should be able to move the location of the
database files and the backup files (by pointing the alias to a different
physical location) without me, as a user of the system, even knowing that
things have changed. I still open database "Mydatabase", do backups to
"Mydatabsebackup".

That's the whole purpose of the database alias, it uncouples the physical
location of the database from the logical database name that the program
will access. Why should not the backup location be subject to the same
rules?

If somebody in IT decides that MyDatabase now should be located in
\\server2\ instead of \\server1\  they should be able to move the files,
point the alias to the new location, and that's that. The same thing should
be true of the backups. With your scheme, I have an application that in
order to do a backup needs to know server names, subfolders, etc. Not good.
And in particular, hard to explain to IT administrators. Why should I go to
an application program in order to change the location of files? Makes no
sense.

As to the issue of who decides when to do a backup, I have several
applications that know when to do a backup. It happens with no operator
intervention whatsoever. Tim, in real life you don't give people that many
choices. You tell them "at this point in the process, you do a backup" or
better yet, you do it for them. Don't think that "the user executing the
task should definitely know which  destination directory they're putting the
backup in (among several other  important pieces of information)." That's
not real life. You tell them "at 3:30 PM, you run the backup". That's about
it.  They don't know the "directory" they are going to, nor do they care.

Robert

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote on Wed, 6 Sep 2006 23:08:26 -0400

>not real life. You tell them "at 3:30 PM, you run the backup". That's about
>it. They don't know the "directory" they are going to, nor do they care.
>

If fact they may well not even know what a "directory" is!

I'm with Robert on this one.  _None_ of our users have anyone who could be called a DBAdmin, most of them can barely use basic Windows stuff like Explorer (for some this is the first encounter with a computer) and that's OK because we write the applications that they use and they shouldn't have to worry about the technical stuff.

Cheers


Jeff

--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

>  _None_ of our users have anyone who could be called a DBAdmin

Indeed, this is why I like DBISAM - you can set it all up and manage it
from your own code. I'll confess I've not used the client/server, but I'd
have to work out a good way of resolving this I think.

Presumably a work-around is to have a table of aliases, and the server-
side installer could create this and set the local location path for the
backups. Then the client doing the backup could read the table on the
server and get the path to be used. Thus the administrator could use a
server-side (or client side I suppose) app to change that alias. This
provides what is required, but it would be nice to not have to implement
it for each developer.

/Matthew Jones/

Robert,

<< Look, the person executing the backup does not "know" anything. It is the
program that "knows". And how does the program find out? It either uses a
database alias (good) or it has a hardcoded path (bad). >>

Did you know that you can very easily find out the path of a database in
DBISAM via this method ?

http://www.elevatesoft.com/dbisam4d5_tdbisamsession_getremotedatabase.htm

If the user isn't inputting the path, then just use this method to retrieve
the path from the database server and use the retrieved path in the backup
method call.  I was under the impression that you *wanted* the user to input
the backup desinatation path.

<< My only point is that a C/S DBAdmin system should allow me to login to
any terminal as a "user who can do backups", and perform a backup regardless
of this specific terminal mappings, >>

Terminal mappings have nothing to do with it.  The path required by the
backup is relative to the server machine, not relative to the workstation.

<< Also, the IT administrator should be able to move the location of the
database files and the backup files (by pointing the alias to a different
physical location) without me, as a user of the system, even knowing that
things have changed. I still open database "Mydatabase", do backups to
"Mydatabsebackup". >>

See above.

<< That's the whole purpose of the database alias, it uncouples the physical
location of the database from the logical database name that the program
will access. Why should not the backup location be subject to the same
rules? >>

Because it isn't a database path, it's a physical path where backups are
stored.  If you want to decouple the backup path for the user in your
application, then feel free to do so.  However, we will not be changing the
backup to use a database alias for the backup destination.

<< Tim, in real life you don't give people that many choices. >>

Okay, now you're lecturing me, and that is not acceptable.  I've been
developing applications for over 16 years now, and I know very well what
it's like in *real life*.

Here are your choices:

1) If you want an unattended backup, then code a scheduled event in the
database server to do a scheduled, unattended backup every day, etc.:

http://www.elevatesoft.com/dbisam4d5_customizing_engine.htm

2) If you want the user to initiate the backup, then either the user must
know what directory to store the backup in or your application must know by
querying the database server for it, either via a database path or via a
server-side procedure that returns paths to use for database backups:

http://www.elevatesoft.com/dbisam4d5_customizing_engine.htm
http://www.elevatesoft.com/dbisam4d5_calling_server_procedures.htm

As far as I can see, that covers every possible combination of needs that
one might have.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:2B6F61A5-BEFF-4A53-82F5-C0E3B11AAF01@news.elevatesoft.com...
> Robert,
>
> << Look, the person executing the backup does not "know" anything. It is
> the program that "knows". And how does the program find out? It either
> uses a database alias (good) or it has a hardcoded path (bad). >>
>
> Did you know that you can very easily find out the path of a database in
> DBISAM via this method ?
>
> http://www.elevatesoft.com/dbisam4d5_tdbisamsession_getremotedatabase.htm
>

You have to be connected as an administrator, the way I understand it. It's
a possibility, but it still does not give the DBAdmin the option to say "the
backup for MyDatabase goes from now on to drive E:", and have the program,
without modification, seamlessly continue doing its backups which now get
stored on a different drive, maybe different media altogether. I guess we
could create two databases, one for the data, one for the backup, with some
name convention that will allow me to query the server for the location of
the backup. Clunky but feasible.

> If the user isn't inputting the path, then just use this method to
> retrieve the path from the database server and use the retrieved path in
> the backup method call.  I was under the impression that you *wanted* the
> user to input the backup desinatation path.
>

What I want is "backup MyDatabase to MyDatabaseBackup", where both are
aliases set up by the administrator.

> << My only point is that a C/S DBAdmin system should allow me to login to
> any terminal as a "user who can do backups", and perform a backup
> regardless of this specific terminal mappings, >>
>
> Terminal mappings have nothing to do with it.  The path required by the
> backup is relative to the server machine, not relative to the workstation.
>

OK, the semantics was wrong. My point is that no hardcoded paths should be
necessary in C/S.

>
> << That's the whole purpose of the database alias, it uncouples the
> physical location of the database from the logical database name that the
> program will access. Why should not the backup location be subject to the
> same rules? >>
>
> Because it isn't a database path, it's a physical path where backups are
> stored.

And the database alias points to a physical path where the data tables are
stored. Conceptually, no difference.

If you want to decouple the backup path for the user in your
> application, then feel free to do so.  However, we will not be changing
> the backup to use a database alias for the backup destination.
>

Your system, your choice.

> << Tim, in real life you don't give people that many choices. >>
>
> Okay, now you're lecturing me, and that is not acceptable.

What is not acceptable is that you get your panties in a bunch on a
civilized discussion on system design. The fact is that everybody that has
chimed in into this thread thinks that my request is valid (and, please
remember, they happen to be your customers), and I'm looking for the best
solution, not to be "right" or "wrong". I just have trouble explaining to a
customer something that I myself consider illogical. You don't convince that
your system is correct using logic, you just dictate based on the fact that
you are the boss. Fine. I'm sure I'll come up with an adequate workaround.

Unbelievable.

Robert

Robert,

<< You have to be connected as an administrator, the way I understand it. >>

It's a simple matter to connect to the admin port via a separate session at
application startup to retrieve this information.  The user doesn't even
need to know that it is going on.

<< It's  a possibility, but it still does not give the DBAdmin the option to
say "the backup for MyDatabase goes from now on to drive E:", and have the
program, without modification, seamlessly continue doing its backups which
now get stored on a different drive, maybe different media altogether. >>

Yes it does, provided that you change the database path using the facilities
in DBISAM for doing so.  The same is required when you move a database to a
different location.

<< I guess we could create two databases, one for the data, one for the
backup, with some name convention that will allow me to query the server for
the location of the backup. Clunky but feasible. >>

It's basically exactly what you want.

<< What I want is "backup MyDatabase to MyDatabaseBackup", where both are
aliases set up by the administrator. >>

See above.

<< OK, the semantics was wrong. My point is that no hardcoded paths should
be necessary in C/S. >>

Practically every single database server out there uses hard-coded
paths/volume information for backups.  Here's a link to MS SQL Server's
backup info:

http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlbackuprest.mspx#EMMAC

<< And the database alias points to a physical path where the data tables
are stored. Conceptually, no difference. >>

They're more than just that - databases in DBISAM are not just aliases.  And
with ElevateDB they are definitely way more than just an alias.

<< What is not acceptable is that you get your panties in a bunch on a
civilized discussion on system design. >>

If you feel that my comments were out of line, then I apologize.  However,
the problem I have here with your comments is that you don't seem to want to
take my answer as the final say.  Sometimes decisions have to be made that
are contrary to what some customers feel is correct, and this is one of
those cases.  As I stated in my very first response - backups are executed
from the context of the database server.  Therefore, the backup path must be
specified relative to the database server.  I've given you alternatives that
will do what you want, so hopefully that is enough.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:CE1B27A4-C1C8-4CEA-B8F1-692F6D7DF5D2@news.elevatesoft.com...
>
> Practically every single database server out there uses hard-coded
> paths/volume information for backups.  Here's a link to MS SQL Server's
> backup info:
>
> http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlbackuprest.mspx#EMMAC
>

This is not what we were talking about, and you know it. The question is
doing a backup from inside your program, where you conceivably don't even
know the name of the server, let alone if drive D: in the server is a CD or
a tape or a hard drive. All you have at the terminal level is an IP address
in the HOSTS file, and a database alias. So when somebody in IT reconfigures
the server, my application crashes trying to backup to the wrong device.
Lovely.

> those cases.  As I stated in my very first response - backups are executed
> from the context of the database server.

So is a table.open, but for that I don't need to know the physical path in
the server, just the IP address of the server and the alias of the database.
Go figure.

Anyway, I'm done with this conversation. I'll find a solution.

Robert

Why would you want to backup one database to another database? The
backups in DBISAM are compressed monolithic files not resembling a
database. Am I missing something here?

If DBISAM backups were simply a copy operation of all tables, then I
could understand a database to database operation.