| Subject | Re: [firebird-support] Re: gbak -c error of "size specificatation" |
|---|---|
| Author | Helen Borrie |
| Post date | 2012-05-15T20:33:06Z |
At 04:40 AM 16/05/2012, bwc3068 wrote:
Anyway, that "size" message refers to file size, not page size. The default page from FB 1.5 onward is 4K, prior to that 1K. From FB 2 onward, it won't let you create pages smaller than 4K.
The problem here is that, if you're not specifying secondary files, you shouldn't be seeing that message. That falls back to the ability of your filesystem to create a file. You're saying it's on an NTFS partition. Could that be an old partition that dates back to NT 4 days, with the accompanying file size limitations?
Are you running Classic? and what version of Firebird?
Your example is a bit sparse on syntax:
gbak -c aaa.fbk aaa.gdb
Remember that the backup file is just a file and needs a full file specification. The backup file can be anywhere in the filesystem, *including* a share, and has a local path.
A database file is a database and should be addressed through a server location. With Classic on Windows, you need to provide the location of the server (specifically, the Services Manager) as Classic doesn't support the "Windows local" protocol. But, even if you're using Superserver, you'll still need to provide a legal location. An implicit location lands up in the current directory which, if you're running gbak from its default location in the \bin\ directory of your Firebird installation, which might not be a legal write location on recent versions of Windows.
And, of course, Firebird will *not* create a database on a share.
So, for a reality check, check first that the destination location for the database doesn't already have a file named aaa.gdb from a former botched attempt. If it does, delete it. Then, tell us what happens when you present the gbak command with full syntax:
gbak -c -se localhost:service_mgr d:\backups\aaa.fbk d:\backups\aaa.gdb -user uname -password whatever
In this example, d:\backups\aaa.fbk is a valid location for reading from or writing to a backup file, even if partition d: is a network share. But it's not valid at all as a destination location for aaa.gdb if partition d: is not a physical location controlled by the host machine. Without the -se localhost:service_mgr switch, aaa.gdb is not a valid location for a database file with Classic.
./heLen
>good thought...vk5?
>
>i tried. when i added -page_size 2048
>
>it came back with "page size specified (2048 bytes) rouded up to 4096.
>
>4096 and 8192 just returned the same original error message:
>
>ERROR: size specification either missing or incorrect for file vk5
Anyway, that "size" message refers to file size, not page size. The default page from FB 1.5 onward is 4K, prior to that 1K. From FB 2 onward, it won't let you create pages smaller than 4K.
The problem here is that, if you're not specifying secondary files, you shouldn't be seeing that message. That falls back to the ability of your filesystem to create a file. You're saying it's on an NTFS partition. Could that be an old partition that dates back to NT 4 days, with the accompanying file size limitations?
Are you running Classic? and what version of Firebird?
Your example is a bit sparse on syntax:
gbak -c aaa.fbk aaa.gdb
Remember that the backup file is just a file and needs a full file specification. The backup file can be anywhere in the filesystem, *including* a share, and has a local path.
A database file is a database and should be addressed through a server location. With Classic on Windows, you need to provide the location of the server (specifically, the Services Manager) as Classic doesn't support the "Windows local" protocol. But, even if you're using Superserver, you'll still need to provide a legal location. An implicit location lands up in the current directory which, if you're running gbak from its default location in the \bin\ directory of your Firebird installation, which might not be a legal write location on recent versions of Windows.
And, of course, Firebird will *not* create a database on a share.
So, for a reality check, check first that the destination location for the database doesn't already have a file named aaa.gdb from a former botched attempt. If it does, delete it. Then, tell us what happens when you present the gbak command with full syntax:
gbak -c -se localhost:service_mgr d:\backups\aaa.fbk d:\backups\aaa.gdb -user uname -password whatever
In this example, d:\backups\aaa.fbk is a valid location for reading from or writing to a backup file, even if partition d: is a network share. But it's not valid at all as a destination location for aaa.gdb if partition d: is not a physical location controlled by the host machine. Without the -se localhost:service_mgr switch, aaa.gdb is not a valid location for a database file with Classic.
./heLen