On 31 August 2011 18:06, Milan Babuskov mil...@panonnet.net wrote:
**
Nick Upson wrote:
the commandline used is
gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
/opt/unb/archive/tmp/110831130601.fdb
User/pass have no effect unless you give localhost: in front of
looking at the logs for other processes, all of the last four occurrances
happened at the same time as an isql session was run against the original
database.
I can't think why there is any need for this isql session and the gbak
session creating the new database to interact via the lock manager
Nick Upson wrote:
looking at the logs for other processes, all of the last four occurrances
happened at the same time as an isql session was run against the original
database.
I can't think why there is any need for this isql session and the gbak
session creating the new database to interact
On 1 September 2011 14:19, Milan Babuskov mil...@panonnet.net wrote:
**
Nick Upson wrote:
looking at the logs for other processes, all of the last four occurrances
happened at the same time as an isql session was run against the original
database.
I can't think why there is any need
more info, the last few lines of -v output from gbak are:
gbak:activating and creating deferred index FK_APABSE_LASTMODBYID
gbak:activating and creating deferred index FK_APBASE_CREATORID
gbak:activating and creating deferred index FK_TBLACTIVEPOWER_TBLELEMENT
gbak:activating and
the commandline used is
gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
/opt/unb/archive/tmp/110831130601.fdb
On 31 August 2011 11:45, Nick Upson n...@telensa.com wrote:
more info, the last few lines of -v output from gbak are:
gbak:activating and creating deferred index
Nick Upson wrote:
the commandline used is
gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
/opt/unb/archive/tmp/110831130601.fdb
User/pass have no effect unless you give localhost: in front of
connection string. Try:
gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
