Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 22 total |
RESTORE DATABASE |
Mon, Jun 1 2009 8:05 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | I'd like to see the RESTORE DATABASE FROM <BackupName> 1. not bomb if the backup name contains a file extension and 2. accept extensions other than that in the configuration.
I think I know where you're coming from but users have the option of moving their backups wherever they like and also of changing names and extensions. As long as its a valid backup I think it should be accepted. The way I'm doing it I'm going to be creating and dropping the store as part of the process. I could rename the file to match what's in the configuration but I don't think I should have to. Ideally for backup and restore I'd prefer to just be able to specify a directory but I'm pretty certain I won't get that and creating and dropping stores whilst annoying isn't a problem. Roy Lambert |
Mon, Jun 1 2009 12:04 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I'd like to see the RESTORE DATABASE FROM <BackupName> 1. not bomb if the backup name contains a file extension and 2. accept extensions other than that in the configuration. >> You can change the backup extension in the session configuration in the EDB Manager, or in the engine/session configuration in the TEDBEngine/TEDBSession components, depending upon where you're using the TEDBEngine.UseLocalSessionEngineSettings property. << I think I know where you're coming from but users have the option of moving their backups wherever they like and also of changing names and extensions. As long as its a valid backup I think it should be accepted. >> The extensions need to be agreed upon in order to have the system Configuration tables work properly: http://www.elevatesoft.com/manual?action=mantopic&id=edb2sql&category=3&topic=48 It's how EDB iterates the available backups for restoration, especially over a remote connection to a machine where you don't have actual physical access to any of the directories on the machine. This is also the basis for the store functionality. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Jun 1 2009 2:11 PM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
I've just spent the last hour or two trying to write this one. I don't want to come across as antagonistic and I think there's a major danger of that. I can see the sort of lock down you seem to be aiming at here being appropriate and suitable for the enterprise version when it arrives since it will be pure c/s. I can also see it being generally the best approach for those using ElevateDB in c/s mode but for those of use Luddites using fileserver I think its awkward. I can program my way round the (what seem to me) restrictions you're building in (eg why do I have to define a Store when I want to do a backup or export a table). In many cases its trivial stuff, but when there's no benefit to me (being selfish here) its very annoying. What I think I'm asking for is that whilst you continue to support fileserver mode can you look at making things a bit easier for fileserver users. I know that the fundamental stuff isn't going to change but the periphery which is what I regard backup/restore as could allow for fileserver as well as client/server. Unless, of course, there are dire consequences of doing so. Out of interest what percentage of ElevateDB customers aren't buying c/s? Roy Lambert |
Tue, Jun 2 2009 2:05 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< I can program my way round the (what seem to me) restrictions you're building in (eg why do I have to define a Store when I want to do a backup or export a table). In many cases its trivial stuff, but when there's no benefit to me (being selfish here) its very annoying. >> But, you're assuming that there isn't any benefit when the benefit is always there - you can move your application to using the EDB Server, even over a WAN, with no changes to your databases or configurations. << What I think I'm asking for is that whilst you continue to support fileserver mode can you look at making things a bit easier for fileserver users. I know that the fundamental stuff isn't going to change but the periphery which is what I regard backup/restore as could allow for fileserver as well as client/server. Unless, of course, there are dire consequences of doing so. >> Well, the issue is documentation and support. What you're suggesting is a situation similar to DBISAM where local and C/S required two different ways of specifying database paths, which in turn requires all sorts of documentation and clarification about which way works for each access method. Furthermore, it makes a local application *less* portable to C/S, and vice-versa. Plus, in all honesty, we're not talking about a really huge amount of effort. One SQL statement to create/alter the store to point to the desired location, and then one SQL statement to set the current store so that you can get a list of backups to restore. Or, you could adapt to the EDB way of doing things and simply have your application require that all backups go in a pre-configured location. << Out of interest what percentage of ElevateDB customers aren't buying c/s? >> EDB has been a lot more C/S than DBISAM, and the majority of EDB customers are at least purchasing the C/S version. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Jun 3 2009 2:33 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
><< I can program my way round the (what seem to me) restrictions you're >building in (eg why do I have to define a Store when I want to do a backup >or export a table). In many cases its trivial stuff, but when there's no >benefit to me (being selfish here) its very annoying. >> > >But, you're assuming that there isn't any benefit when the benefit is always >there - you can move your application to using the EDB Server, even over a >WAN, with no changes to your databases or configurations. And you're assuming that at some point I will want to change to C/S - nah <vbg> >Well, the issue is documentation and support. What you're suggesting is a >situation similar to DBISAM where local and C/S required two different ways >of specifying database paths, which in turn requires all sorts of >documentation and clarification about which way works for each access >method. And I (like most programmers) always regard having to do documentation as DIRE! >Furthermore, it makes a local application *less* portable to C/S, >and vice-versa. Accepted, but, as I said, I'm being selfish. I don't care about porting to C/S >Plus, in all honesty, we're not talking about a really huge >amount of effort. One SQL statement to create/alter the store to point to >the desired location, and then one SQL statement to set the current store so >that you can get a list of backups to restore. Its actually this amount of effort ForceDirectories(buLocation); try dm.TfRSession.Execute('DROP STORE "buTfR" KEEP CONTENTS'); except end; dm.TfRSession.Execute('CREATE STORE "buTfR" AS LOCAL PATH ' + QuotedStr(buLocation)); DoBackup.Close; buName := dm.DB.Database + ' (' + dm.TfREngine.DateToSQLStr(Now) + ')'; Unique := ''; Cntr := 64; while FileExists(IncludeTrailingPathDelimiter(buLocation) + buName + Unique + dm.TfRSession.LocalBackupExtension) do begin inc(Cntr); Unique := Chr(Cntr); end; buName := buName + Unique; dm.TfREngine.Close; DoBackup.SQL.Text := 'BACKUP DATABASE ' + dm.DB.Database + ' AS "' + buName + '" TO STORE "buTfR" INCLUDE CATALOG'; Progress.Visible := True; DoBackup.ExecSQL; dm.TfRSession.Execute('DROP STORE "buTfR" KEEP CONTENTS'); One of the things that really flummoxed me was the need to strip the extension off because ElevateDB added it on. >Or, you could adapt to the >EDB way of doing things and simply have your application require that all >backups go in a pre-configured location. Nope - I'm awkward, plus I want to allow for users to backup to / restore from removable media. ><< Out of interest what percentage of ElevateDB customers aren't buying c/s? > >> > >EDB has been a lot more C/S than DBISAM, and the majority of EDB customers >are at least purchasing the C/S version. Not to surprising, it is much more c/s orientated than DBISAM. I'll bet you get no fileserver customers for the enterprise version when it comes out It would be interesting to know how many other Luddites there are out there developing fileserver or standalone PC apps using ElevateDB. Roy Lambert |
Wed, Jun 3 2009 4:08 AM | Permanent Link |
"Malcolm" | Roy Lambert wrote:
> It would be interesting to know how > many other Luddites there are out there developing fileserver or > standalone PC apps using ElevateDB. > > > Roy Lambert One here! -- |
Wed, Jun 3 2009 5:25 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Malcolm
Whereabouts are you? Roy Lambert |
Wed, Jun 3 2009 7:15 AM | Permanent Link |
"Malcolm" | Roy Lambert wrote:
> Malcolm > > > Whereabouts are you? > > Roy Lambert When you posted I was in Sainsbury's, but I am now back home (Edinburgh) about to consume my purchases. -- |
Wed, Jun 3 2009 7:25 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Malcolm
How do you fancy starting a UK Luddites society - we ritually disembowel anyone mentioning c/s Roy Lambert |
Wed, Jun 3 2009 10:39 AM | Permanent Link |
"Malcolm" | Roy Lambert wrote:
> Malcolm > > > How do you fancy starting a UK Luddites society - we ritually > disembowel anyone mentioning c/s > > Roy Lambert Hi Roy I am certainly up for ritual disembowelment. But yon Tim seems to be a decent bloke and I would not wish to deprive him of any of his bread and butter. Would expense fiddling politicians be an acceptable alternative target group? I can't think of any negative impact from loosing a few hundred of them! Malcolm -- |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |