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

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

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

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

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

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!

--

Malcolm


Whereabouts are you?

Roy Lambert

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.

--

Malcolm


How do you fancy starting a UK Luddites society - we ritually disembowel anyone mentioning c/s

Roy Lambert

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

--