Subject | Re: [IBO] Re: Admin components |
---|---|
Author | Mark Pickersgill |
Post date | 2004-10-07T05:36:35Z |
Russell,
A couple of things, IBOAdmin (from memory) uses whatever DLL you
throw at it in the same way as IBObjects uses whatever DLL you throw at
it. ie You can solely use the fbclient.dll file if you wish providing
you take the same steps as you would for any IBObjects app that you
wanted to use the fbclient.dll.
The IBOAdmin backup and restore services use the same Firebird
administrative services API as gbak. Hence you CAN do a live/hot backup
of a database using the IBOAdmin backup service.
As far as I know in Firebird 1.5.x there is no way to kick users off to
produce a completely up-to-date backup or perform a restore.
To get around this problem in my apps, I have created a TCP/IP server
service that performs extra functions, such as stop users from logging
into a system that is wanting to perform a restore, getting a file list
of previously backed up files, getting the full-path of a backup folder
(FB has a short-coming of not being able to specify a folder alias as
opposed to a file alias :( ), and broad-casting a friendly message to
users who are currently in the system but need to exit the system so a
backup/restore can be done.
So with that you can politely ask users to exit the system, give them 5
minutes to do so, then try again until there's no-one connected to the
database except the person doing the backup/restore.
Mark
russellbelding wrote:
A couple of things, IBOAdmin (from memory) uses whatever DLL you
throw at it in the same way as IBObjects uses whatever DLL you throw at
it. ie You can solely use the fbclient.dll file if you wish providing
you take the same steps as you would for any IBObjects app that you
wanted to use the fbclient.dll.
The IBOAdmin backup and restore services use the same Firebird
administrative services API as gbak. Hence you CAN do a live/hot backup
of a database using the IBOAdmin backup service.
As far as I know in Firebird 1.5.x there is no way to kick users off to
produce a completely up-to-date backup or perform a restore.
To get around this problem in my apps, I have created a TCP/IP server
service that performs extra functions, such as stop users from logging
into a system that is wanting to perform a restore, getting a file list
of previously backed up files, getting the full-path of a backup folder
(FB has a short-coming of not being able to specify a folder alias as
opposed to a file alias :( ), and broad-casting a friendly message to
users who are currently in the system but need to exit the system so a
backup/restore can be done.
So with that you can politely ask users to exit the system, give them 5
minutes to do so, then try again until there's no-one connected to the
database except the person doing the backup/restore.
Mark
russellbelding wrote:
>Thank you Helen, Don and Mark for your comments.
>
>Mark I did have GDDS32.dll in the Win System32 directory and I likely
>misdiagnosed why I did not get the IBOAdmin.BackupService working.
>
>Helen I downloaded your example and it works (after setting the
>backup folder in your ini file).
>
>I am interested in a backup and restore capability for the usual
>reasons. To my knowledge only GBAK can correctly save a live FB
>database file. Should a site using one of our FB apps upgrade their
>version of FB and want to benefit from a new ODS they must use a GBAK
>backup and restore. To use a GBAK restore requires, more or less, no
>users be actively using the DB file. So some method of disconnecting
>all users, forcibly if necessary, and preventing new connections, is
>desired as the safest way to do a restore. I do not know if this
>disconnection and prevention is built into IBOAdmin's restore
>component. I suppose not.
>
>It is easy to imagine a way to achieve disconnection and prevention
>if we require each connection to be registered in a table. When a
>restore is requested an event notification will be sent to all
>applications. The connected user count can be examined by the
>application requestion the restore. Other actions and details follow.
>
>At present it seems the IBOAdmin Backup requires the client library
>be named GDS32.DLL. On my setup with no GDS32.DLL's on client or
>server, Helens sample program failed because GDS32.DLL was not
>available. In the IBOAdmin source is no use of "GDS32.DLL". (but
>maybe I have missed something) So I have not figured out how to
>change IBOAdmin so it will use FBCLIENT.DLL. (I haven't tried hard.)
>
>At present the FB 1.5.1 fbclient.dll can be renamed gds23.dll and the
>renamed file will work on our IBO applications. I am not sure if this
>will be true with new FB versions. So continued use of GDS32.DLL may
>not be possible.
>
>IBO uses gds32.dll and to get it to use fbclient.dll can change the
>only name in IB_SESSION511.pas file to "FBCLIENT.DLL".
>
>So using the IBOAdmin backup and restore services is not my first
>choice to achieve a FB backup and restore. The disconnect and prevent
>problem is not handled, I think, and it requires GDS32.DLL.
>
>By contrast gbak.exe requires fbclient.dll and will not run with only
>gds32.dll present. I have gbak.exe in my main program directory, and
>am using it to now to perform backups and later restores, on the DB
>server. The details are in CH38 of the Big Firebird Book.
>
>Don if Lorenzo Mengoni is responding perhaps he would be interested
>in commenting. Any other insight or corrections?
>
>Kind regards
>
>Russell Belding
>
>
>