At 03:28 AM 26/04/2005 +0000, Feroz wrote:

>.
>i am still lost what to do.

You don't mention whether you read my earlier response and tried to correct
your connection strings.

>here are more details:
>1) I am using FB 1.5.2 SuperServer and IB 6.0.2 in my Development
>Environment on WinXP SP2 machine (I only run one server at a time,
>although I am able to run both using different ports).
>2) I created a backup file (ACROSYS.GBK) from Production Environment
>which runs IB 6.0.2 on Win2K Server machine.
>3) I tried to restore this on my develoopment machine with IB 6.0.2
>and did not suceed.
>4) I also tried to retore with FB 1.5.2 and it did not work (I
>renamed the GBK to FBK).
>5) Both restores give the same problem.
>6) This time I used tools to restote : IBOConsole and Workbench.
>7) Using IBOConsole, the log says as follows:
>Service started at 4/26/2005 11:02:27 AM
>gbak: opened file D:\data\ACROSYS.FBK
>gbak: transportable backup -- data in XDR format
>gbak: backup file is compressed
>gbak: created database D:\data\ACROSYS.FDB, page_size 8192 bytes
>gbak: started transaction
>gbak: restoring domain MATRIC_NO
>gbak: restoring domain CLG_CODE
>gbak: restoring domain CRS_CODE
>
>--> then it works fine until
>
>gbak: restoring data for table STUMST
>gbak: 3632 records restored
>gbak: restoring index RDB$PRIMARY7
>gbak: restoring index I_CRSREGCRE_MATRIC_NO
>gbak: restoring index I_CRSREGCRE_STR_CODE
>gbak: restoring index I_CRSREGCRE_CRS_CODE
>gbak: restoring data for table CRSREGCRE
>gbak: 10000 records restored
>gbak: 20000 records restored
>gbak: 30000 records restored
>gbak: 40000 records restored
>gbak: 50000 records restored
>gbak: adjusting an invalid decompression length from -96 to -36
>gbak: 51607 records restored

OK, so IBOConsole handles the problem record in CRSREGCRE and then trips up
on an unrecognised table attribute in the definition for the next table --

>gbak: do not recognize table attribute 0 -- continuing
>gbak: do not recognize table attribute 0 -- continuing
>gbak: do not recognize table attribute 0 -- continuing

... it tries to carry on anyway

>--> and it prompts the message window with error code 336330798
>and says string truncated.

--- until it reaches an error it can't handle (a string trying to go into a
column that is too short for it).

>With Workbench, log says:
>gbak: opened file D:\data\ACROSYS.FBK
>gbak: transportable backup -- data in XDR format
>gbak: backup file is compressed
>gbak: created database D:\data\ACROSYS.FDB, page_size 8192 bytes
>gbak: started transaction
>gbak: restoring domain MATRIC_NO
>gbak: restoring domain CLG_CODE
>gbak: restoring domain CRS_CODE
>
>--> and works fine until
>
>gbak: restoring data for table STUMST
>gbak: 3632 records restored
>gbak: restoring index RDB$PRIMARY7
>gbak: restoring index I_CRSREGCRE_MATRIC_NO
>gbak: restoring index I_CRSREGCRE_STR_CODE
>gbak: restoring index I_CRSREGCRE_CRS_CODE
>gbak: restoring data for table CRSREGCRE
>gbak: 10000 records restored
>gbak: 20000 records restored
>gbak: 30000 records restored
>gbak: 40000 records restored
>gbak: 50000 records restored
>ERROR: invalid request handle
>gds_$send failed

OK, the only difference here is that Workbench apparently doesn't swallow
the first exception.

>But susprisingly, on Production Environment (Win2k Server & IB
>6.0.2), restoring does not give any problem.
>
>I beleive, it is related to some corruption in the data. I hope you
>can help me out here.

It might be corruption, or it might be that you are simply using the wrong
version of gbak for Firebird 1.5.2 and/or IB 6.0.2.

If you suspect corruption, go to the IBP website and pick up this document:

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr

On the production system, stop the server and take a file copy of the
database. Copy it to the development machine and make another file copy of
it.

Then follow the steps on the worksheet exactly, to find out what gfix and
gbak can determine about the corruption (if any).

It might help to take a fresh gbak from the production machine and make
certain it has completed before you try to copy it. It might merely be the
case that you didn't do that last time.

Apart from that I don't know what to suggest, other than re-checking that
your database and backup paths are correct. It might help to take a fresh
gbak from the production machine and make certain it has completed before
you try to copy it. The problem could be simply that you didn't do that
last time.

./heLen