| Subject | Re: [firebird-support] Re: Aliases |
|---|---|
| Author | Woody |
| Post date | 2005-09-14T16:17:14Z |
From: "Adam" <s3057043@...>
access to the firebird folder.
which I am doing, you have to backup to the server relative path. I don't
want to shell out to gbak and the workstation won't have gbak anyway. The
problem is that in order to do an on-the-fly backup before updating DDL, you
must have some sort of relative path on the server. The workstation has
mapped drives to some common, shared folders so maybe I can use one of those
and convert it to a relative path on the server.
Any other suggestions?
Woody (TMW)
> --- In firebird-support@yahoogroups.com, "Woody" <woody-tmw@g...>Security, in so far as access is concerned, is a requirement so no one needs
> wrote:
> > Is there a service API call, utility or component that will let a
> remote application read the aliases.conf file in order to ascertain
> the actual pathname of an alias? I know for security reasons that
> it's not a healthy thing to do but there must be a way.
>
> No, and if there was I woulld want it disabled by default. That said,
> it is a really trivial task to create a service using some layer like
> RemObjects that you could call. Look if security is such a low
> requirement for you, then share the Firebird folder (read only of
> course).
access to the firebird folder.
>If you use gbak, you can backup to a local file. However, when using the API
> >
> > Here's what I am trying to do. When I send an update for a program
> to a client, some DDL changes might be needed. I have the program
> testing for an update SQL in the program network install directory
> the first time the admin runs the updated program. If it requires the
> database structure to change, I want to backup the database before
> making the changes. In order to do that remotely, however, I need a
> path on the firebird server, not an alias. The alias will work for
> the file being backed up, but the destination path must be relative
> to the server, so I want to just create the backup in the same
> directory as the original db.
>
> I would check this because I don't believe it is true. You can
> download the backup file to the client machine.
which I am doing, you have to backup to the server relative path. I don't
want to shell out to gbak and the workstation won't have gbak anyway. The
problem is that in order to do an on-the-fly backup before updating DDL, you
must have some sort of relative path on the server. The workstation has
mapped drives to some common, shared folders so maybe I can use one of those
and convert it to a relative path on the server.
Any other suggestions?
Woody (TMW)