Hello Alan,

Thanks for your final comment.

Alan wrote:

>I must say, I've always avoided this methodolgy so I can't vouch for it personally. I can see what you need to do and I have always convinced my clients that remote admin of this sort is not optimum.
>I prefer this method (but it's not remote-able)
>1. shutdown database (if operating) if out of hours, then stop FB service.
>2. rename db file. (only achievable if noone is connected) if this fails then someone is connected.. fix this issue.
>3. turn service on (if off in 2)(no file available to users - they error out if they try to connect but you've warned them well in advance of maintenance outage)
>4. backup and restore to yet another name (noone knows the name and can't connect til you're ready)
>5. rename file to original filename if no errors restoring (this action is atomic in nature)
>
>All other maintenance of backup / test restore nature is carried out while people are connected. This (above) operation is only done once a year. I argue they can pay me to do it once a year. And for this reason it's not worth me putting it into the client application.
>
>

I see your point, Alan. Partly I can agree.

Unfortunately in this case the admin function shall become part of the
application server. The Firebird server runs under Linux and I might
have to outsource the task of doing an exclusive backup & restore to a
Kylix & RemObjects application in order to get hold of the database file
on the Linux box if I follow your instructions. But as we control the
app server and are the authors of the pool of threads reading from the
database and have only 1 thread writing to the database we might be able
to enforce the "exclusiveness" within our app server rather than the
Firebird server. I'll keep you informed. ;-)

Thanks for your help!!!

Salut,
Mathias