Subject | Re: [firebird-support] segmentation fault |
---|---|
Author | Helen Borrie |
Post date | 2004-10-18T06:57:09Z |
At 08:27 AM 18/10/2004 +0200, you wrote:
go carefully.
1. Shut down the Firebird server.
2. Make a file-copy of the db you have been using and put it somewhere it
can be connected to by your IB 5.x server.
3. Rename the original (the one you have lately been using) to prevent
users logging in.
4. With IB 5.6 running, attempt to do a gbak -b -t of the copy, using IB
5.x's gbak.
5. If the gbak succeeds, copy the backup file to where it is accessible by
the Fb 1.5 server.
6. Now, attempt to restore it using gbak -c and the Fb 1.5 version of gbak.
7. If the restore completed, start the Fb 1.5 server and attempt to
connect to it. Test a few things to make sure it's OK.
8. Shut down the Fb 1.5 server and file-copy or restore into the database
directory.
If there are problems, probably recreating the database from script and
then doing a datapump is going to be your only way out of this corner.
In any event, it is important that you go to the Downloads>InterBase page
at www.ibphoenix.com and get the IB 6 Data Migration Guide. There are
quite a lot of issues you need to know about, regarding the different ways
the two ODS versions store and handle data.
default. If you are trying to connect to the database from a remote Linux
client, you will possibly need the client library named libfbclient.dll at
the client, instead of libfbembed.dll. It may or may not be in the CS bin
directory. If not, you'll need to get it from the SS package.
NOTE that, if you are using a libgds.so, it's wrong. If you need to load a
library named libgds.so from your application, make a symlink for it from
libfbclient.so.
./heLen
>On Monday 18 October 2004 02:11, Helen Borrie wrote:If you just copied it, then it is still an IB 5 database. At this point,
> > At 10:43 PM 17/10/2004 +0200, Christophe Eicke wrote:
> > >Hi!
> > >
> > >I have a pretty big problem. Recently we have switched our old InterBase 5
> > >database to a new server and also upgraded to using firebird
> > >1.5.1.4481-0.i686. I have just copied the old database to the new server
> > > and it worked pretty soon.
> >
> > You have not responded to the replies that were given when you posted this
> > question last week.
>
>My mistake, I didn't see the replies...
>
> >
> > 1. Did you just *copy* the database, or did you back it up on the IB 5.x
> > server using IB 5.x's gbak program, using gbak -b -t ? And then, did you
> > copy the backup file to the new server and restore it using Fb 1.5's gbak,
> > gbak -c and the correct switches for a dialect 1 database?
>
>No, I did not, I just copied the database. What difference does it make? The
>problem now is that there are two databases (the one on the old server and
>the new one with changes already made into it) with different information
>content. Would it help to "gbak -b -t" the new one and "gbak -c" it back
>again?
go carefully.
1. Shut down the Firebird server.
2. Make a file-copy of the db you have been using and put it somewhere it
can be connected to by your IB 5.x server.
3. Rename the original (the one you have lately been using) to prevent
users logging in.
4. With IB 5.6 running, attempt to do a gbak -b -t of the copy, using IB
5.x's gbak.
5. If the gbak succeeds, copy the backup file to where it is accessible by
the Fb 1.5 server.
6. Now, attempt to restore it using gbak -c and the Fb 1.5 version of gbak.
7. If the restore completed, start the Fb 1.5 server and attempt to
connect to it. Test a few things to make sure it's OK.
8. Shut down the Fb 1.5 server and file-copy or restore into the database
directory.
If there are problems, probably recreating the database from script and
then doing a datapump is going to be your only way out of this corner.
In any event, it is important that you go to the Downloads>InterBase page
at www.ibphoenix.com and get the IB 6 Data Migration Guide. There are
quite a lot of issues you need to know about, regarding the different ways
the two ODS versions store and handle data.
> >OK, then the client library libfbembed.dll will have been installed by
> > >Since then we have had some problems with a couple of queries where the
> > >server
> > >would drop all the connections to the database (it's from about 20 - 30
> > >clients), it was no big deal. Until now we found out that the server does
> > > not accept CREATE TABLE statements, using the ISQL client from a windows
> > > client or directly on the database server. On the database server I get a
> > > "segmentation fault" and ISQL quits.
> > >We are running firebird on a slackware 9.0 with kernel 2.4.6.
> > >Any help would be greatly appreciated!
> >
> > 2. Did you install the correct client libraries and isql versions on the
> > client machines?
>
>yes I did
>
> >
> > Also
> > 3. Did you install the Classic version or Superserver on the slackware
> > box?
>
>Classic version
default. If you are trying to connect to the database from a remote Linux
client, you will possibly need the client library named libfbclient.dll at
the client, instead of libfbembed.dll. It may or may not be in the CS bin
directory. If not, you'll need to get it from the SS package.
NOTE that, if you are using a libgds.so, it's wrong. If you need to load a
library named libgds.so from your application, make a symlink for it from
libfbclient.so.
./heLen