| Subject | Re: [firebird-support] Restore from IB - do not recognize table attribute 18 |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-01-15T21:30:39Z |
At 02:43 AM 16/01/2009, you wrote:
By "requisite" I mean - you would need to have both the IB7 client and the Firebird client to hand and first test whether the Fb client can connect to the IB7 database and vice versa, as the application itself will connect to both servers with the same client library.
Note that IB_SQL loads the first client it finds in the path: fbclient.dll or gds32.dll. Since you are reading from the IB database and writing to the Firebird one, I'd choose the Firebird client if it reads the IB database OK.
Note: if the Solaris platform is Sparc (not Intel) I don't think this would be quite so straightforward, as the casting in the application space would assume an Intel target and there would be Endian issues. There are probably other ways around it but the one that comes to mind is to create the transitional database on an Intel machine (which could be a Windows or Linux machine), pump into that one, then back up the new DB and restore it on the Sparc platform.
./hb
>2009/1/15 Milan Babuskov <milanb@...>:If not, and you have access to a Windows machine with the requisite client library installed, you can use (free) IB_SQL from www.ibobjects.com It has a Datapump tool that you can use in a multi-server transaction.
>>
>> To dump: isql -a
>
>For metadata it's good but I also need the data itself.
>
>> To pump: fbcopy
>>
>> I haven't tried fbcopy with IB, but it reportedly works.
>
>That should do it. I hope it will run on Solaris.
By "requisite" I mean - you would need to have both the IB7 client and the Firebird client to hand and first test whether the Fb client can connect to the IB7 database and vice versa, as the application itself will connect to both servers with the same client library.
Note that IB_SQL loads the first client it finds in the path: fbclient.dll or gds32.dll. Since you are reading from the IB database and writing to the Firebird one, I'd choose the Firebird client if it reads the IB database OK.
Note: if the Solaris platform is Sparc (not Intel) I don't think this would be quite so straightforward, as the casting in the application space would assume an Intel target and there would be Endian issues. There are probably other ways around it but the one that comes to mind is to create the transitional database on an Intel machine (which could be a Windows or Linux machine), pump into that one, then back up the new DB and restore it on the Sparc platform.
./hb