At 03:32 AM 27/03/2009, you wrote:

>Hi All.
>
>I ve a FDB on which when i run a query on a join of two tables it gives me a error saying
>
>" I/O error 'DB PATH' "

This is not a valid format for any message sent by Firebird. If Firebird could not find a database file, you would see a message like
I/O error for file "/full/path/to/database.fdb" (on POSIX)
or
I/O error for file "D:\full\path\to\database.fdb" (on Windows). You should also see SQL code -902, isc code 335544344 and/or the symbol io_error.

If the above message (wherever it came from) is your only evidence, then it is not evidence that your database is corrupt or even that it is the database file that is causing the problem. For example, if the query contained a sort (DISTINCT, ORDER BY or GROUP BY) then the engine would need to find the sort directory and create temporary files there; or, if a table involved in the query is an external table, then the engine would need to find the external file; or that some file access is blocked; and so on..

>I tried using GFIX with -v and -full options but, everytime it only shows the error, but does not fix them.

>Please guide me how to use GFIX in a efficient way to recover an FDB.

gfix does not "recover an FDB". It can be used, in combination with gbak, to repair errors in the page structures of a database, or in its page inventory. There is a full, detailed guide at the IBPhoenix website:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr
which should be followed exactly, working on a !!!! file copy !!!! only.

But, to repeat, if that error message is coming out of an active database connection, then it is not due to database corruption. Try using isql to run the query and note down exactly the FULL content of the exception messages: that should bring you closer to what the exception really is.

./heLen