Adam pisze:

>
>
> --- In firebird-support@ yahoogroups. com
> <mailto:firebird-support%40yahoogroups.com>, "Branimir Trumbic"
> <seronimo@.. .> wrote:
> >
> > Just some unrelated questions that is bugging me and I didn't find
> > right answer:
> >
> > 1. What is difference between database connection string "C:\MyDb.fdb"
> > and "localhost:C: \MyDb.fdb" , or in other words what is difference
> > between 'direct access' and 'tcp' access?
>
> GBak and NBackup are conceptually different beasts.
>
> Imagine you wrote a tool that did the following:
>
> * Connect to the database (in the same method as any other client
> program).
> * Query the system tables to get the table structures, index
> definitions, constraints etc, then wrote these out to a file.
> * Run a select * from each table, then wrote these out to a file.
>
> Congratulations, you just wrote gbak.
>
> Now imagine you wrote a different tool that did the following.
>
> * Flag the database to tell the database engine it is not allowed to
> write to the file any more, but instead it must keep track of any
> changes inside a delta file.
> * Read the database file directly byte-by-byte from the disk and write
> those bytes to a destination file.
> * Flag the database to tell the database engine it is now allowed to
> write to the file again, and that it needs to synchronise the changes
> in the delta file.
>
> Congratulations, you just wrote NBackup.
>
> (Apologies for oversimplifying what happens under the hood).
>
> So conceptually, there is no difference between running gbak on the
> server or on a client machine; just like in any client-server
> application there is no difference (apart from speed) whether the
> client and server are the same machine or not.
>
> But NBackup, by the way it works, must be able to take a byte-wise
> copy of the database file. Normally such a byte-wise copy would
> potentially cause corruption, but because it has temporarily flagged
> the database in such a way that the database engine will not touch the
> file during the copy it is safe in this case.
>
> In terms of your earlier presumption that gbak does database cleaning
> as it goes, this is true by default but if you use the -g switch, it
> does not. Gbak is still a lot slower than NBackup. The reason is
> simple. GBak is treating the database like a logical data store, and
> so must obey access rules in terms of record level visibility etc. On
> the otherhand, NBackup is simply streaming bytes between files.
>
> Adam
>

From your description I see nothing which prevents usage of nbackup
through the services API, of course not yet implemented.
Are there any future plans to merge nbackup support into services API ?


Boguslaw