Subject | Re: Argggh - unavailable database -904 |
---|---|
Author | turbomenda |
Post date | 2005-05-11T18:41:32Z |
--- In firebird-support@yahoogroups.com, "lance8086" <lance8086@y...>
wrote:
localhost:db synax, the db communcation is way slower. I mean a gbak
restore works 10x slower when connected this way. It seems to actually
send all the data through the network adapter (checked that with my FW
net activity monitor)
I ecountered the same problem as hay77772000 on quite a few machines
and would also be very interested to hear a solution.
At the moment I have an even weirder situation associated with that
problem on my desktop PC (XP Pro SP2).
I have a .bat script that downloads a set of Firebird database backups
from a corporate FTP and then restores the backups on my PC (where I
have a copy of FB installed locally). The script contains gbak calls
like this one:
"D:\Program Files\Borland\InterBase\bin\gbak.exe" -r -page_size 4096
-use_all_space -user SYSDBA -password xxxxx -one_at_a_time -verbose
e:\Praca\baza\grot.gbk e:\Praca\baza\szamocin.ib -Y
E:\Praca\Baza\szamocin.log
e:\Praca\baza\grot.gbk is the backup file
e:\Praca\baza\szamocin.ib is the DB file stored locally on my PC
The scripts runs OK (it restores the databases) no matter if I'm
logged onto the Administrator account or my other account.
Now I've scheduled the script (Control Panel -> Scheduled tasks) to be
run at 6:00 at the morning each day with Administrator privileges. And
guess what - when run as a scheduled task it gives me the "Unavailable
database" message and does not restore the DB.
When I use the localhost:e:\Praca\baza\szamocin.ib syntax it works
both called from a console or when run by the Windows scheduler.
When I use the direct db file path (local server syntax) it only works
when called from console, and doesn't work as a scheduled task
I hope this different case can help somemone identify the problem.
lance: I wish I could just use the localhost: syntax and forget about
this, but the databases are 1.5GB each. A full restore via "local
server" connection takes 40 minutes for all the 3 databases. Doing the
same via TCP/IP localhost: connection takes hours and hours, making
the whole script useless as the idea was that the databases would be
restored before came to work :-)
Laters,
Marcin
wrote:
> If all else fails, don't worry about it.Well there is one big problem with that. When connected with the
> (I know - it bugs you that it doesn't work).
> Just put an entry in aliases.conf
> olympus=(path to database)
> and connect with 'localhost:olympus'
> Consolation prize - its less typing.
localhost:db synax, the db communcation is way slower. I mean a gbak
restore works 10x slower when connected this way. It seems to actually
send all the data through the network adapter (checked that with my FW
net activity monitor)
I ecountered the same problem as hay77772000 on quite a few machines
and would also be very interested to hear a solution.
At the moment I have an even weirder situation associated with that
problem on my desktop PC (XP Pro SP2).
I have a .bat script that downloads a set of Firebird database backups
from a corporate FTP and then restores the backups on my PC (where I
have a copy of FB installed locally). The script contains gbak calls
like this one:
"D:\Program Files\Borland\InterBase\bin\gbak.exe" -r -page_size 4096
-use_all_space -user SYSDBA -password xxxxx -one_at_a_time -verbose
e:\Praca\baza\grot.gbk e:\Praca\baza\szamocin.ib -Y
E:\Praca\Baza\szamocin.log
e:\Praca\baza\grot.gbk is the backup file
e:\Praca\baza\szamocin.ib is the DB file stored locally on my PC
The scripts runs OK (it restores the databases) no matter if I'm
logged onto the Administrator account or my other account.
Now I've scheduled the script (Control Panel -> Scheduled tasks) to be
run at 6:00 at the morning each day with Administrator privileges. And
guess what - when run as a scheduled task it gives me the "Unavailable
database" message and does not restore the DB.
When I use the localhost:e:\Praca\baza\szamocin.ib syntax it works
both called from a console or when run by the Windows scheduler.
When I use the direct db file path (local server syntax) it only works
when called from console, and doesn't work as a scheduled task
I hope this different case can help somemone identify the problem.
lance: I wish I could just use the localhost: syntax and forget about
this, but the databases are 1.5GB each. A full restore via "local
server" connection takes 40 minutes for all the 3 databases. Doing the
same via TCP/IP localhost: connection takes hours and hours, making
the whole script useless as the idea was that the databases would be
restored before came to work :-)
Laters,
Marcin