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?

2. Can multiple database clients safely connect to the same database
using direct access method ("C:\MyDb.fdb")? Under 'safely' I mean: no
database corruption, deadlocks, transactions are safe, no multi thread
problems or other problems that can be caused by concurrent database
connections.

I was under impression that if more then ONE database client is using
SAME database, that all connections must go through TCP layer
(localhost or remote) to ensure database stability (I'm using FireBird
as superserver (as service) on Windows Server OS).



Thanks,

Branimir


--- In firebird-support@yahoogroups.com, "Martijn Tonies"
<m.tonies@...> wrote:

>
> Hi,
>
> > > Why do you need a localhost prefix? NBackup is expected to work fine
> > > without it, regardless of the TCP port of the FB server.
> >
> > I need TCP, because I don't want 'direct access to the database file'
> > as I understand that this kind of access is not multi-thread safe. All
> > my database clients are connected to the database through TCP
> > (localhost).
>
> NBackup only works by using direct access (via the server), you can
> safely continu working on the database. Thread safety has nothing
> to do with it.
>
> > > > 3. Is full nbackup database dump (-B0 option) compatible with

the gbak

> > > > dump and vice versa?
> > >
> > > Nope, they're completely different beasts.
> >
> > Pity, but I understand that gbak is doing some 'database cleaning'
> > while performing backup and nbackup does not. If I start to use
> > nbackup for regular backups, is there any other tool that can be used
> > to 'maintain compact' database?
>
> gbak will not "maintain compact" the database either, it -can- clean
> up the garbage, but the database file(s) will stay the same size.
>
> > - when making full backup, seems that whole database file is copied to
> > the backup file, prior to this nbackup seems to lock database with
> > ALTER DATABASE BEGIN BACKUP thus allowing somewhat safer copy...
>
> Not a "somewhat safer copy", this functionality was -exactly- created
> for NBackup.
>
> > - when restoring database, original database file must not exist, you
> > have to delete it manually
> > - when making incremental backups u are never exactly sure what is
> > last full backup file from which incremental backup is done. I
> > recently found that you can find last full backup in the
> > RDB$BACKUP_HISTORY syste table, sort by date and find last backup with
> > level 0
> > - only thing that I can say is that I've tested nbackup on 'live
> > database with connected clients' and it seems to work without error
> > and very fast.
>
> Which is what is was created for.
>
> > - with all these in mind and with warning that nbackup versions prior
> > to 2.1.1 can cause database deadlock probably I should give up on
> > incremental backups for firebird database until nbackup becomes more
> > stable.
> >
> > Final question:
> > Does anybody actually use nbackup for database backups? Anyone has
> > practical experiences with this tool?
>
> Martijn Tonies
> Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB,

Sybase

> SQL Anywhere, Oracle & MS SQL Server
> Upscene Productions
> http://www.upscene.com
> My thoughts:
> http://blog.upscene.com/martijn/
> Database development questions? Check the forum!
> http://www.databasedevelopmentforum.com
>