Subject | Re: [firebird-support] Embedded / Backup |
---|---|
Author | Helen Borrie |
Post date | 2004-12-07T00:28:29Z |
At 10:54 AM 7/12/2004 +1100, you wrote:
embedded can take one and only one user connection, it's not possible for
gbak to connect to the database while your user application is connected.
database before invoking the Execute method of the
IBOAdminBackupService. This is probably contrary to the way you usually
write applications for multi-user use. Mostly, we combine the startup of
our IBO database apps with the database connection, i.e. we tie the
creation of the main form to the activation of the db connection. Though
its' what most of us do most of the time, it's not necessarily the best way
to implement connections if you want to write scalable apps. It doesn't
make sense for multi-tier, for example. Admin tools like IBExpert, et al.,
don't do it, of course, since they have no way at startup to know what
database they are going to connect to.
Instead, you need to make your main form's creation "data access neutral",
able to connect and disconnect on demand and use code to test the state of
connections before allowing the user 's request to back up or to connect
for data access to proceed. Alternatively, your application can listen for
the exception and respond accordingly.
Actual implementation questions belong in the IBO list.
./hb
>Someone has asked this before but noone answered..Gbak makes its own connection to a database. Since a database under
>If you use the embedded server and you want to backup the database under
>application user control, what do you do?
embedded can take one and only one user connection, it's not possible for
gbak to connect to the database while your user application is connected.
>I notice that IBExpert can do this but I'm not sure how they do it...You would have to write the application so that it disconnects from the
>What would be the call if you use IBObject components?
database before invoking the Execute method of the
IBOAdminBackupService. This is probably contrary to the way you usually
write applications for multi-user use. Mostly, we combine the startup of
our IBO database apps with the database connection, i.e. we tie the
creation of the main form to the activation of the db connection. Though
its' what most of us do most of the time, it's not necessarily the best way
to implement connections if you want to write scalable apps. It doesn't
make sense for multi-tier, for example. Admin tools like IBExpert, et al.,
don't do it, of course, since they have no way at startup to know what
database they are going to connect to.
Instead, you need to make your main form's creation "data access neutral",
able to connect and disconnect on demand and use code to test the state of
connections before allowing the user 's request to back up or to connect
for data access to proceed. Alternatively, your application can listen for
the exception and respond accordingly.
Actual implementation questions belong in the IBO list.
./hb