Jason

>Why would you want to backup one database to another database?

They don't

What Robert wants to do is use a database alias and allow the engine to expand that to the full path name so that some user sitting at a workstation halfway round the world can click the button labeled "backup now" (or possibly a timer fires) and it sends a command to the server "backup databaseA to databaseB" and the engine in the server expands this to

backup all the files held in physical directory A to the physical directory B

The debate centres around Robert wants the server to use its table of alias' vs directories and Tim wants the directory to be supplied

Robert's approach makes for easier (and possibly more consistent) programming, Tim's for greater flexibility

Or at least that's my take on it.

<WindUp ON>
In my view there's much more interesting things to debate like should NULL = ''
<WindUp OFF>

Roy Lambert

"Jason Lee" <computerguy@wavecable.com> wrote in message
news:E6BFF943-7196-42F2-91A8-30162B28DAE4@news.elevatesoft.com...
> 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?
>

It's just a scheme to allow me to use the server's alias mechanism to find
out the physical location (from the server's point of view) of the backup.
There are no tables in the backup "database", it is just an alias pointing
to a folder.

Robert

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:96F2D851-019E-4684-A69B-07FD0768CAFF@news.elevatesoft.com...
>
> backup all the files held in physical directory A to the physical
> directory B
>

Well, not exactly. It is

backup all  the files held IN DATABASE ALIAS A    to PHYSICAL DIRECTORY B.
Very inconsistent. For the source we use an alias, for the destination a
hardcoded path.

Robert

Robert


>backup all the files held IN DATABASE ALIAS A to PHYSICAL DIRECTORY B.
>Very inconsistent. For the source we use an alias, for the destination a
>hardcoded path.

Yes but in DBISAM terms DATABASE = physical directory

I was just doing what the server/engine has to do before it can do anything to nay table

Roy Lambert

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

Robert,

I haven't toyed with coding a dedicated DBISAM server yet, but my
impression is that you can modify it to suit your needs. If you have the
source code version of DBISAM can't you just write an server side procedure:

procedure Backup(ADatabaseName: String);

and just maintain a configuration file on the server that says where the
backup goes?

I can even imagine a server side routine that would automatically name
the backup by date and maintain a copy of each of the last weeks
backups, one for each week before that, and one for each month before
that and delete the other daily backups as they are not needed.

Sean

"Sean McCall" <someone@somewhere.net> wrote in message
news:D979E0E6-7625-4471-A709-2FC87B787EB0@news.elevatesoft.com...
>
> I haven't toyed with coding a dedicated DBISAM server yet, but my
> impression is that you can modify it to suit your needs. If you have the
> source code version of DBISAM can't you just write an server side
> procedure:
>
> procedure Backup(ADatabaseName: String);
>
> and just maintain a configuration file on the server that says where the
> backup goes?
>

Sure. There are several options. But your solution would require the use of
an INI file of sorts that would have to be supported by a custom program. I
was just trying to avoid the use of ANY program other than the Server
Administration Utility to establish the connection between aliases and
physical locations. That way, when they move my application to another
server (which folks periodically do, for a number of reasons) they only have
to deal with one program. Gives folks less opportunity to screw things up,
forget to change the backup location, start the app on the new server and,
when it gets time to do backup, boom! Call to Robert at midnight.

Robert

Robert


>Sure. There are several options. But your solution would require the use of
>an INI file of sorts that would have to be supported by a custom program. I
>was just trying to avoid the use of ANY program other than the Server
>Administration Utility to establish the connection between aliases and
>physical locations. That way, when they move my application to another
>server (which folks periodically do, for a number of reasons) they only have
>to deal with one program. Gives folks less opportunity to screw things up,
>forget to change the backup location, start the app on the new server and,
>when it gets time to do backup, boom! Call to Robert at midnight.

OK so you have two programs to customise - the server and the admin utility.

Roy Lambert

Robert,

<< This is not what we were talking about, and you know it. >>

What I linked to is exactly the same implementation as with DBISAM.  Backups
executed from their admin utility require a path name (relative to the
database server) for the destination file.  In what way is that different
than our implementation ?

<< 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. >>

This is only true if you completely ignore everything that I've posted on
the subject so far regarding modifying your application to make it immune to
this scenario.

<< 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. >>

That's a false analogy - a backup and a table open are two completely
different operations.   And a backup doesn't require the physical path to
the database, only to the destination backup file.

What you're failing to realize is that someone might have a legitimate
opinion on this subject that is different from your opinion.  I guarantee
you that if we changed it to use aliases for backup locations, someone would
immediately complain because it would require them to set up an alias before
they could backup a database.  Many customers perform the backups on the
database server via a server-side procedure or scheduled event and don't get
the client application involved with anything other than possibly initiating
the backup by calling the server-side procedure that executes it.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:541AB1DB-0DB2-4141-9FC1-93B112C3CF3D@news.elevatesoft.com...
>
> << 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. >>
>
> That's a false analogy - a backup and a table open are two completely
> different operations.

Thanks for sharing.

And a backup doesn't require the physical path to
> the database, only to the destination backup file.
>

Exactly my point. It is an instruction to the server, "move data from A to
B" where A is an Alias aand B is a hardcoded path. Not consistent.

Look at it this way. Say tomorrow you provide the capability of splitting
the database between two volumes. Part of the tables are "here", the other
part "there". Does my application need to know, when it does a JOIN, that
one table is here and the other there? O course not. It goes to the database
alias, and the server knows where all the pieces are. Somebody in IT decided
to split the tables to get better performance, went to the server admin and
connected the alias to "here" and to "there", moved some tables to here and
other to there, and done deal. I don't need to know. IMO, when we do a
database backup, it should be the same. The server knows. It is no business
of the application to know server drives or paths.

> What you're failing to realize is that someone might have a legitimate
> opinion on this subject that is different from your opinion.

And what you're failing to realize is that this is not a matter of
"opinion". I have given you what I consider clear reasons why any server
paths should be done via aliases not hardcoded directories, since they are
relative to the server, not the workstation. It makes no sense to me to have
an application have to know that drive D on the server is this or that.
While you basically have told me "that's the way it is". Look, if your way
is better, I'd LOVE to be convinced. So far, no luck.

I guarantee
> you that if we changed it to use aliases for backup locations,

Use an overload method, or create something called "remotebackup", or
something like that.

someone would
> immediately complain because it would require them to set up an alias
> before they could backup a database.  Many customers perform the backups
> on the database server via a server-side procedure or scheduled event and
> don't get the client application involved with anything other than
> possibly initiating the backup by calling the server-side procedure that
> executes it.
>

The server side procedure is no solution. It still requires a special
program to maintain an INI file where the path to the path to the backup is
stored. Unless, of course, you are suggesting that it should be hardcoded in
the program

Anyway, we'll have to agree to disagree. As I said in the other posting,
I'll come up with a solution.

Robert

Robert,

<< Thanks for sharing. >>

You know, the smart-ass comments show that my first impressions were
correct..  You're basically starting from a position where you think you've
got it all figured out, and I'm just an ignorant rube that needs to be
taught how things should be done.  Well, I retract my apology for my
original comments, and you can simply shove that attitude right up your ass.
How's that for consistent ?

--
Tim Young
Elevate Software
www.elevatesoft.com