I read from your post that once the "Begin backup" was executed,
whatever thread wants to insert a record into the database will be
blocked until the "End backup" was executed.

May be I am a bit on the safe side, I used semaphore to allow one of
many threads to update the database table to track what files had been
processed based on what IP or UNC path the file originated, file size,
and last write time. My daemon process forks a thread for each type
of files to be monitored for file processing from one of houndreds of
business partners that send files to me. I added database tracking
using Firebird so I know if the same file become "sticky" due to
various reason that the daemon process was not able to delete/rename
after pulling if down from the remote FTP Server.

So from you post, are you stating that "spsudo concurrent" threads
each inserting record to the same table of the embedded FB database
file is safe without a need to synchronize their access?

Jeff


--- In firebird-support@yahoogroups.com, "Ivan Prenosil"
<Ivan.Prenosil@...> wrote:

>
> > So from Ivan's post, it seems that if my management thread gain
> > exclusive access to the database by gaining the semaphore first,
> > followed by excuting the "ALTER DATABASE BEGIN BACKUP" SQL before
> > start file copy, and executes the "ALTER DATABASE END BACKUP" will
> > address the problem of having the backed up copy of the database file
> > being corrupted.
>
> You do not need any semaphore. While the database is locked by

"ALTER DATABASE

> BEGIN BACKUP" the Firebird will not touch the db file, but you do

not need

> to interrupt your work with that db because all changes are sent to

temporary file.

>
> Ivan
>