I can tell you from lots of experience, you can create extreamly large backup
files with gbak.
There was a time that our backups created a single 27 GB backup file on our NTFS
partition.

best regards

Dalton

Bill Karwin wrote:

> > From: "Jason Chapman" <jason@...>
> > 1) It appears that I will have a _Major_ problem when
> > the backup file breaches 2GB as Gsplit is not supposed
> > to work under NT - what am I going to do?
>
> I think gbak files don't suffer from the 2GB limit, because it has no need
> to treat gbak files as random-access files. It treats them more like a tape
> device. That is, a stream of data. Since NTFS seems to support files
> larger than 2GB, I think you can create a huge gbak file and restore from it
> too.
>
> It's worth a test to make sure, though. :)
>
> > 2) ... The secondary file seems to not believe in relative
> > addressing ...
> > Whichever, it means that I must always have the GDB
> > in the same location, i.e. e:\data\sqldata\DBName which
> > has just made my database a whole lot less portable.
>
> This is an often-cited "gotcha" with multi-file databases. The path to the
> secondary files is written in the header page of the primary gdb file, and
> there is currently no tool that can alter these paths. You might be able to
> do it with a binary editor (make sure no one is attached to the database!).
> But you might have to ensure that the paths have the same number of
> characters.
>
> It would be challenging to do so in the general case, because if there are
> many files with long pathnames, the list can easily fill up the header page.
> InterBase allocates more header pages as necessary to store all the
> filenames. The extra header pages are not necessarily contiguous.
>
> The system table RDB$FILES stores the paths of secondary files and shadow
> files, but this is read-only; changing these values _doesn't_ change where
> InterBase looks for the secondary files.
>
> Ideally, there should be a tool to edit the header page(s), or perhaps
> syntax for the ALTER DATABASE statement to change the location of secondary
> files. This would have to work even if (especially if) the database could
> not be readied due to mislocated secondary files.
>
> This problem doesn't seem like it's unsolvable. It's a good candidate for a
> contributed enhancement after IB 6.0 is released and the source is opened.
> Whomever does it would be a hero!
>
> Bill Karwin
>
> ------------------------------------------------------------------------
> Now the best and coolest websites come right to you based on your
> unique interests. eTour.com is surfing without searching.
> And, it's FREE!
> http://click.egroups.com/1/3013/3/_/830676/_/956785660/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com