Hi,

Weird stuff like this happened to us when we upgraded from Interbase
v4.x to 5.x (a long time ago). In our case it was from us having
triggers doing stuff that wasn't allowed in the newer version of
Interbase so our backup worked fine, but the restore failed, but in a
way that we ended up with the data present, but all of the triggers and
stored procedures missing. We just changed our trigger code and then it
worked fine. This probably has nothing to do with your problem, but I
thought I would share it anyways...

-steve

On Wed, 2005-08-31 at 13:40 +0000, spongebob7487 wrote:

> Keep in mind that the original goal of the backup/restore exercise
> was to upgrade from Interbase to Firebird at about 80 remote
> locations. We use the following steps to accomplish this (some paths
> and file names have been changed to protect the innocent):
>
> 1) Shutdown all running applications that could be accessing the
> database.
>
> 2) Make a phyical copy of the database file in case something
> goes wrong. (ex: copy c:\database.gdb c:\backup\database.gdb)
>
> 3) Use IBConsole (under Interbase 6.0) to make a backup of the
> database to a .gbk file. The options used are the defaults:
> format=transportable, metadata only=false, garbage collection=true,
> transactions in limbo=process, checksums=process, convert to
> tables=false, verbose output=to screen.
>
> 4) Uninstall Interbase and Interclient.
>
> 5) Reboot
>
> 6) Install Firebird Super Server using the default options (version
> 1.5.2.4731)
>
> 7) Install JayBird JDBC driver
>
> 8) Restore the database from the command line using GBAK (Firebird
> version) with the following syntax:
>
> cd c:\Program Files\Firebird\Firebird_1_5\bin
>
> gbak �c �user SYSDBA �pas password c:\backup\database.gbk
> localhost:/database.gdb
>
> 9) Add users and change application specific JDBC connection strings
> to point to the JayBird driver and Firebird database server.
>
> I should note that we have had problems on both Windows 2000 and
> Windows XP. I can guarantee that the original database was not
> manually shutdown before the backup. As for the owner of the tables
> being SYSDBA, I have seen that reported out here before. One thing
> that I have just noticed is that we don't end up adding the original
> owner of the database tables to the Firebird security file until
> AFTER the restore has been processed. Is it possible that the
> restore is failing because the owner of the tables done during the
> backup is not on the system when the restore takes place? One final
> note, the process listed above has worked on 10 other machines
> without any issues.
>
> Thanks,
> Matt
>
> --- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
> wrote:
> > At 08:37 PM 30/08/2005 +0000, you wrote:
> > >I have a client who performed a backup and restore using the GBAK
> > >routine. When we try to connect to the resulting database we get
> > >the "database [database name] shutdown" error. Does anyone know
> what
> > >could be causing this?
> >
> > The database that was backed up was shut down.
> >
> > >Here are some more details.
> > >
> > >1) I can "fix" the issue by bringing the database back online
> using
> > >the GFIX -online option. However, this just lets users other than
> > >SYSDBA connect. There are data integrity issues (see below).
> > >
> > >2) All of the database tables are completely empty. None of the
> data
> > >was restored.
> >
> > If the restore operation completed without throwing any
> exceptions, then it
> > looks likely the backup was done as a "metadata only" one.
> >
> >
> > >3) The owner of each table is SYSDBA instead of the real owner
> > >assigned in the original database.
> >
> > That doesn't make sense.
> >
> >
> > >4) No one ever manually "shut the database down". GBAK must have
> > >done it during the restore (or else never got to the point where
> it
> > >brings it online in the first place).
> >
> > It depends. Something looks fishy about the backup. When a gbak
> is being
> > restored on a Fb 1.5 Superserver, the gbak program has an
> exclusive lock on
> > the file until it completes the task and logs out.
> >
> >
> > >5) We are upgrading from Interbase 6.0 to Firebird 1.5. The backup
> > >was made using GBAK against the Interbase database.
> >
> > What server was running when the IB 6 database was backed up?
> >
> > Which gbak was used?
> >
> > On each side, is gbak being called from the command line or
> through an
> > application?
> >
> > Exactly what switches are being used on each side?
> >
> > Did the switches used include -v and -y to create logs?
> >
> > >The restore was made using GBAK from version 1.5 of Firebird.
> >
> > Superserver or Classic? Which sub-release? Which OS platform?
> >
> >
> > >It appears that either the backup or restore failed to complete
> > >(probably the restore). Any ideas as to why this happens?
> >
> > Not from the info thus far provided. Both IB and Firebird (can)
> do hot
> > backups, i.e. the database doesn't have to be in a shutdown state
> for the
> > backup. The backup will be done in a single snapshot transaction
> that
> > reflects the state of the database when the process starts.
> >
> > > It actually happened on two different databases/machines today
> so we
> > > are really getting spooked.
> >
> > Does this statement tell us that you are running IB6 and Fb 1.5 on
> the same
> > machine and are arbitrarily connecting to the same database
> through one or
> > the other server?
> >
> > What about the client library?
> >
> > ./heLen
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>


[Non-text portions of this message have been removed]