"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:B03776AF-62DA-4B5A-92EE-5CC19A52F141@news.elevatesoft.com...
> 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 ?
>

I think you need a few sessions with Jerry to work out that anger. Or a
vacation. Or both. Maybe you can trade with him for an upgrade to V4. Once
you fix this problem with the backup, of course.

Otherwise, probably better to ignore this posting. If I were you, I'd delete
it from the server.

Cordially,

Robert

Okay, I get it. In that case what I do is just modify the DBSRVR project
to read an ini file for the location of the backups directory. Then,
either in a scheduled event or when a user selects "backup", the server
knows where to put the backup. That way, my end users do not need to
know anything about backup locations, database names, etc.

Granted, my end users are fairly computer illiterate.

Also, they can perform a "remote backup" whereby the server performs the
backup and then streams the backup file back to the user to save on
their computer or memory stick, etc.

Also, we have a scheduled event that occurs every evening that creates a
backup and FTPs the file to us for offsite storage. We decided a long
time ago to take backups out of the hands of users (too many times they
have a crash, we ask "Where is your last backup?" they answer "Here it
is, but we last backed up a year ago!" ARGH!)


Roy Lambert wrote:
> 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

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in
news:3E722442-F16E-4E9F-97DF-C11138E31A1E@news.elevatesoft.com:

> It is not a big deal, I've been dealing with it fine in file server by
> always using UNC so I don't have to depend on individual terminal
> mappings. But unless I'm missing something, it seems to me that the
> backup location should be part of the database setup. Just as you
> determine that for this database the files are on a specific folder,
> you should also determine thet the backups go to a specific folder.
> Just to be consistent.
>
> Robert
>
>

Robert,

As usual I'm rather late joining this thread, but I thought I'd just
throw in my 2 cents worth:

It seems to me that what you're looking for is a way to make it easy for:

1/ the user on a client PC possibly many miles from the server to
initiate a backup without knowing or caring where it's going to go

2/ the server administrator to change his server configuration without
needing to worry whether your application is going to explode at the next
backup request from a client PC

I'd expand on Matthew Jones' suggestion of adding a table to the database
with one field holding the server directory used for backing up and
another for a timestamp. You then add a program for the server
administrator which allows him to specify where he wants your backups to
go and inserts a new record, with a new timestamp, whenever he changes
it.

When your client PC asks for a backup, it can just read the last record
in that table and send the directory path to the server.

When your client PC wants to restore a backup, you ask the user for a
date and time and read the last record where the timestamp is earlier
than that to find where the backup is.

What do you think?
--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.24 Build 1)

"Chris Erdal" <chris@No-Spam-erdal.net> wrote in message
news:Xns983DC53DD6AE514torcatis@64.65.248.118...
> "Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in
> news:3E722442-F16E-4E9F-97DF-C11138E31A1E@news.elevatesoft.com:
>
>> It is not a big deal, I've been dealing with it fine in file server by
>> always using UNC so I don't have to depend on individual terminal
>> mappings. But unless I'm missing something, it seems to me that the
>> backup location should be part of the database setup. Just as you
>> determine that for this database the files are on a specific folder,
>> you should also determine thet the backups go to a specific folder.
>> Just to be consistent.
>>
>> Robert
>>
>>
>
> Robert,
>
> As usual I'm rather late joining this thread, but I thought I'd just
> throw in my 2 cents worth:
>
> It seems to me that what you're looking for is a way to make it easy for:
>
> 1/ the user on a client PC possibly many miles from the server to
> initiate a backup without knowing or caring where it's going to go
>
> 2/ the server administrator to change his server configuration without
> needing to worry whether your application is going to explode at the next
> backup request from a client PC
>
> I'd expand on Matthew Jones' suggestion of adding a table to the database

Thanks for the suggestion. My problem is that especially with virtualization
being the rage,  folks are changing server names and file locations more
often than they change their underwear. So anything that keeps it simple and
foolproof (as much as possible, anyway) should help.

Backup is an integral part of may of my applications, and it is always done
from a client. I've come up with a scheme that is a bit clunky, but seems to
work. For every database alias, I create a database alias with the added
letters BU. So database MyData really is two database aliases, MyData and
MyDataBU. MyData, as usual, points to where the tables are. MyDatabaBU is
not really a "database", just an alias to indicate where to store the
backups. If I'm in remote mode, then I ask the server for the location of
MyDataBU, and I use that as a destination for the backup. Since they both
get listed under "databases" in the server admin, it is possible that IT
will only forget to change the location of the backup 10 or 15% of the time.
Not bad.

In local mode, the database folder has a subfolder named backup, and that's
where the backups get stored.

>
> When your client PC asks for a backup, it can just read the last record
> in that table and send the directory path to the server.
>

Yeah, I could also put it in an ini file. In either case, there would be an
additional program to run when you change database and/or backup locations.
I just want to have all the database location issues centralized in one
program. Especially for customers that have more than one of my
applications, IT has only once procedure, one program to use.

Robert

> MyDataBU

Why not "MyDataBackup"? The full word would make for much more
comprehension of the purpose and significance.

/Matthew Jones/