Subject RE: [ib-support] Re: version 1.0.2 destroys isc4.gdb
Author Bert Hughes
My upgrade was from the 821 build to 1.0.2. Before that I was using
Interbase 6.0.1. I've done backups scores of times, restored (to different
machines usually), at least a couple of dozen times. I did get your intent,
and the file (isc4.gdb) was apparently restored. (And thanks again, my
eyeballs were about to pop out). All user/passwords appear to be back.
I.e., programs connecting the the fb databases had Roles, users assigned to
roles. All works. You must supply correct user/password to connect. Both
IBConsole, IBWorkbench see everything under the Registered
Databases/<database> tree. All programs function Ok, connections,
everything. BUT...if I attempt to open the User Manager (IBWorkbench), or
open Users (IBConsole), both fail with the error "unrecognized database
parameter block/unable to open database".
As an experiment, I simply copied isc4.gdb to a new file "security.gdb", and
opened it in IBConsole. No problem.

ISC_USER, ISC_PASSWORD are defined and exported in
/etc/rc.d/init.d/firebird, and has actual SYSDBA/password. This is new - I
changed to actual password, before I had left password at default
"masterkey", with no ill effects, even tho it was wrong. (Not actually
SYSDBA's password). One thing that appears to be new in this file is
FBRunUser=root, I believe the server always used to run as user "interbase".
That could explain the quirky gbak behavior, refusing to connect to password
database if I supplied a user/password.

Still baffled, but I'll leave 1.0.2 running and hope I don't need to
add/edit users before this gets figured out. The bugs 1.0.2 fixes sound
scary, though I never had any of them happen...

Naturally, when I tried the upgrade on a simulation machine (home),
everything worked, though with some difficulty all revolving around
isc4.gdb. Its a critical machine that I have mere minutes to make changes
on that gives me trouble.

Thanks again, and Happy New Year, if its a new year for you.

Bert Hughes

-----Original Message-----
From: Aage Johansen [mailto:aagjohan@...]
Sent: Friday, December 27, 2002 4:24 PM
Subject: [ib-support] Re: version 1.0.2 destroys isc4.gdb

Bert Hughes wrote:
> Something like that almost worked. I was able to restore to a new file,
> like you said, as long as the working directory was not interbase (fb)
> The users are there - but nothing can change - both IBConsole and
> Workbench are unable to read the file. I've run through backup and
> a few times now. Basically, whether you should use the -user -password
> params appears to be random. Sometimes that works, sometimes you have to
> leave it off. No doubt this is completely unreplicatable - before I even
> began working on the production machine, I had tried the upgrade on a
> simulation machine. Similar problems getting isc4.gdb back, but after
> trying about eight or nine different things, including monkeying with
> password in /etc/init.d/firebird, it came back, and no problems reading &
> setting users with IBConsole & Workbench.
> This is very, very bad. I would strongly recommend that no one upgrade
> until this problem is fixed.

Do you have environment variables (ISC_USER and ISC_PASSWORD) defined -
this might explain if -user/-password sometimes work (and aometimes not)
when isc4.gdb has been changed/replaced.

What do you mean by "both IBConsole and Interbase Workbench are unable
to read the file"?
If you have a valid isc4.gdb (and the corresponding password for SYSDBA)
you should be able to connect to the restored database (with IBC, IBW
and other tools).
[I've (later) seen your other message (... - beyond strange). Well, I'm
out of ideas. Maybe Martijn (author of IBW) can explain]

Some time ago I upgraded from Fb/0.9.5 to Fb/1.0(821), and the
restore/rename procedure worked fine (maybe my explanation was a bit off
on some detail, but I think you understood the intention).
It would certainly be a surprise if Fb/1.0.2 is any different (but I
haven't tried...).

Aage J.

To unsubscribe from this group, send an email to:

Your use of Yahoo! Groups is subject to