Do future versions of IB prevent connections during the restore (gbak -r)
process?  In 5.6 the following sequence produces serious problems:

1. shut down database (gfix -shut...)
2. back up database (gbak -b...)
3. restore database (gbak -r...)
4. before restore is finished, connect to database (isql...) as non-SYSDBA
user.

First of all, I think it's sloppy that even though the database is shut
down, a non-SYSDBA user can connect.  The connection is refused after the
restore is complete, but during the restore process no connections are
refused.
Secondly, allowing a connection at all to a restoring database (whether shut
down or not, whether SYSDBA or not) is rediculous since the db can't be in a
known good state at that time.  In fact, the following error message results
when a connection is made during the restore process:

gbak: cannot commit index RDB$FOREIGN10
gbak: ERROR: unsuccessful metadata update
gbak: ERROR:      object <tablename> is in use
gbak: ERROR: action cancelled by trigger (3) to preserve data integrity
gbak: ERROR:     Cannot deactivate primary index
gbak: Exiting before completion due to errors

This has the net effect of making foreign key constraints (which are really
indexes) inactive.  Unfortunately a metadata extraction does not indicate
whether constraints (indexes) are active or not.  Obviously using the
database at this point is problematic because there is no referential
integrity.

What I'm asking for is this:
1. Denial of any connection by any user during the restore process.
2. Report on state of indexes in metadata extraction (active or inactive).
3. Exclusive lock on *.gdb file while in use to prevent copying (and
corrupting).  (I know this doesn't relate to this posting, but I've
mentioned it in previous posts and thought I'd put another plug in for it).

Are any of these features implemented or planned for implementation in IB 6
or 7?

thanks,
Paul J. Mills

To get around your point 1, I rename the database first (to make sure no-
one is accessing it), do the backup, restore the database to a different
name, then finally when the restore has finished I rename the database
back to it's original name.  While I am playing, the app can't find the
database (it was renamed) so no-one can possibly connect :)

Rowdy

"Paul J. Mills" <pjmi...@bgint.com> wrote in news:3d19e088_1@dnews:

<snip>

Thanks for the elementary work-around, but I was really hoping someone from
TeamB or otherwise could tell me when, if ever, the IB server will prevent
connections during the restore process, as well as a suggestion on how to
get the state of indexes/constraints from a metadata extract.

Paul J. Mills

In article <3d1a93d5$1_1@dnews>, pjmi...@sunflower.com says...
        TeamB are volunteers who do not work for Borland and, as such,
cannot know when Borland plans to release particular features.

        As far as the state of the indices go, look at RDB$INDICES.RDB
$INDEX_INACTIVE

        HTH,

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
     Delphi/InterBase WebLog: http://delphi.weblogs.com
     InterBase PLANalyzer (Free IB optimization tool):
          http://delphi.weblogs.com/IBPLANalyzer

Then why have I gotten responses in the past such as, "SMP processing for NT
will be available in IB 7"?  In general I see the reponse, "it's fixed in
the next release" a lot on this NG.

My question is when this information will be reported by isql -x -a (i.e. a
metadata extract)?

thanks,
Paul J. Mills

In article <3d21fd4c$1_1@dnews>, pjmi...@bgint.com says...

        Because TeamB folks tend to pay attention to what Borland says in
public, and this has been stated publicly.

        AFAIK, no.  You might request this feature in QualityCentral.

        -Craig

--
 Craig Stuntz (TeamB) Vertex Systems Corp. Columbus, OH
     Delphi/InterBase WebLog: http://delphi.weblogs.com
     InterBase PLANalyzer (Free IB optimization tool):
          http://delphi.weblogs.com/IBPLANalyzer