![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 22 total |
![]() |
Mon, Jun 1 2009 8:05 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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. ![]() | 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 ![]() | 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. ![]() | 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 ![]() | 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 ![]() 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 ![]() | 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 ![]() (Edinburgh) about to consume my purchases. -- |
Wed, Jun 3 2009 7:25 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | 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, July 2, 2025 at 06:46 PM | Privacy Policy![]() © 2025 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |