I am examining a Windows application that uses a database of unknown type. The database consists of several files with file extensions, .i, .iz, .b1, .p and .bi. Is there an API that can be used to view the design, tables and contents of this database? The ambition is to migrate the data to a MySQL environment.
A:
Perhaps the Unix file utility (available in Cygwin) can identify them.
Marcelo Cantos
2010-10-12 22:21:48
is it useful on a windows application ?
Xaqron
2010-10-12 22:24:30
It's a stand-alone tool that you invoke from the command-line, and its sole purpose is to identify the format of the files you are looking at; it won't know how to work with them. But, assuming it is able to correctly identify the files, you then may be able to find a library or tool that knows how to read that format and do the conversion.
Marcelo Cantos
2010-10-12 22:29:48
+1
A:
Use a hex editor and see db inside in binary mode. You may get the chance to see the file type in the few starting bytes. Then change the extension appropriately and open it.
Xaqron
2010-10-12 22:23:18
A:
From FileExt.com:
File Extension BI
File type: Binary File
Primary association: Binary File
Other applications associated with file type BI:
- Progress (Database Before Image File) by Progress Software Corporation
- Quick Basic or Visual Basic for DOS (Include File) by Microsoft Corporation Similar to C's .H but is used only in Microsoft's DOS BASIC dialects. Stands for "Basic Include". This association is classified as Text.
Anyway...
Chances are that it's not a relational database system that this program uses; most ad-hoc, single-use databases developed for use in one program are what are called "flat-file databases", which means that "records" have a set size and are accessed through a method of seek-ing through it as you would a normal file. For instance, if you set the record size to 20, then the first record would be at the byte range 0-19, the second would be at 20-39, etc.
If you could somehow derive what the record size this particular program uses, you could split the file into the component records as binary data. Decoding that data into meaningful information would probably be a hassle, though.
amphetamachine
2010-10-12 22:26:42