At 10:36 PM 13/01/2006 +0000, you wrote:

>I'm not sure what version of Interbase this file comes from, but I am
>trying to export data
>from a windows application that is using Interbase.

Most third-party admin tools that can connect to an InterBase database will
be able to give you the On-disk structure version of the database. The ODS
is a reasonable clue as to what version of InterBase server created the
database.

>I'm hoping to get it in some sort of semi-generic SQL format

There is no such thing as "generic SQL format". SQL is a language
interface. If a particular database engine's implementation of the SQL
language complies closely to the international standard, then that SQL
implementation might be considered "generic".

So what you really need to tell us is what you need the exported data
for. There are tools around that can convert tables and other DB objects
from one DB engine's native format to another's. Whether the converted
data's structure is directly useful or not depends entirely on the degree
to which each engine's native database architecture is compatible with the
other's. So, for example, Firebird and InterBase data is virtually
interchangeable; Oracle and Firebird data structures are highly
compatible; while the typical ISAM-style structures (e.g. Paradox, MySQL,
Access) need quite a lot of work to make them in productive databases for
use with Oracle or InterBase.

>or if not that, CSV would be okay too.

CSV is but a text file format with some recognised, basic usage conventions
that converting engines can understand, for example, double quotes around
strings that were/should be stored as strings, commas to mark the ends of
all fields other than the last in a record, line-feeds plus or minus
carriage returns to mark the end of a record, and a marker to indicate end
of file. A text file has no ability to store typed data, merely bytes, so
dates have to be encoded for conversion to whatever format is used by the
destination database engine; and the strings that represent number types
are generally recognised by having no field markers.

Again, there are tools out there that can both export and import CSV
according to these conventions.

>The data is stored in a .ib file.

The suffix on a Firebird or InterBase database file has no significance -
it can be anything, or nothing at all. It can provide a clue that it was
created by an InterBase server, since the ".ib" convention was recommended
to developers once the previous convention (".gdb") was hijacked by
Microsoft and caused problems on Windows ME and XP. If your source
database was used on a Win XP server, it could just as well be *any* ODS,
since renaming of databases was imperative in order to make them usable on XP.

>Are there any tools in Firebird that can help me do this?

Several. You might like to visit www.clevercomponents.com where you can
download their free Interbase Datapump. You can look for more by visiting
www.ibphoenix.com and going to the relevant section of the Contributed
Downloads section; and you can also inquire on the firebird-tools list
and/or explore the list archives.

>Do I need to know the database's username and password to access it?

Yes. But if you take a backup of the database and restore it on your own
server, you can access it with your own SYSDBA login credentials. This is
a useful security hole with benefits for anyone who is denied access to the
database in its home server but is not prevented from copying it or backing
it up.

./heLen