Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 21 to 30 of 35 total |
A few question on V4 |
Fri, Sep 8 2006 5:11 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Fri, Sep 8 2006 9:35 AM | Permanent Link |
"Robert" | "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 |
Fri, Sep 8 2006 9:38 AM | Permanent Link |
"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 |
Fri, Sep 8 2006 11:24 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Fri, Sep 8 2006 12:18 PM | Permanent Link |
Sean McCall | 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 |
Fri, Sep 8 2006 12:53 PM | Permanent Link |
"Robert" | "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 |
Fri, Sep 8 2006 2:00 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Fri, Sep 8 2006 4:06 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Sep 8 2006 4:51 PM | Permanent Link |
"Robert" | "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 |
Fri, Sep 8 2006 5:37 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 ? -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 3 of 4 | Next Page » |
Jump to Page: 1 2 3 4 |
This web page was last updated on Wednesday, June 12, 2024 at 01:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |