Thanks you, Adam for your response. Since my daemon has two session
management threads to monitor literally 200 concurrent threads each
either monitor a UNC directory or a FTP data source, I will wait for
the FB2 instead of using the FB Service API.

If I FB2 ends up taking long time to be release, I can always add a
delta logic to my management thread so that I can sieze the semaphore,
close the FB database connection, do the physical file backup then
then reconnect the database.

I am not too picky about the "non-compressed" database because part of
the management thread's job was to trim the database table for records
that are "too old".

Thanks for everyone's responses on this topic to correct my ignorance
of the FB garbage collection thread's function. I thought I was being
creative by using semaphore!

Jeff

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
>
> --- In firebird-support@yahoogroups.com, "Jeff Lynn" <jmlynn@> wrote:
> >
> > I looked up "Alter Database" SQL stmt syntax from the InterBase 6
> > Language Reference manual and did not see anything regarding "Alter
> > database" with the Start/end backup refrence. It this new inf
> > Firebird 1.5x or 2.0?
>
> Hi Jeff,
>
> In my first post I mentioned NBackup was new to Firebird 2 (which is
> not considered stable for production release). The syntax Ivan was
> mentioning is how it operates, and he confirmed (I think) that you
> could do this via a simple SQL statement. It won't be in the IB6
> guides because it is new to FB 2.
>
> If you need to provide compatibility with FB 1.5, then using the
> services API to backup is the best way. I can tell you how this is
> done in Delphi and IBX, but have no idea for other environments. I
> would be surprised if it took longer than an hour to locate enough
> resources to get you going. The advantages of a proper backup are:
>
> 1) No risk that a database in use will be file copied. The semaphore
> approach doesn't handle garbage collection, so if you do take this
> approach, rename the file first to make sure nothing is writing to the
> file.
>
> 2) The backup file is smaller and will often compress further to only
> 10% of the size of the database.
>
> 3) As far as the rest of your program goes, the backup just happens
> without interfering at all.
>
> NBackup does (or rather will in FB2) freeze the database file when you
> issue a begin backup call and start writing changes to a delta file.
> You then take a file copy of the database file which is guaranteed not
> to be modified. When you are done, you make the end backup call, which
> merges the delta file into the database file. I do not know if there
> are performance implications (good or bad) to this approach, and this
> list is not really the place to discuss NBackup until FB2 is released.
>
> Adam
>