Old Foxpro Database files (.inx extension) circa 1995

FoxPro does not recognize .inx file (it knows idx, cdx, and also mdx). .inx is used by Adobe InDesign and InstallShield. Could you please upload some small .inx file? You should rename it to .TXT and you may ZIP it.

Some sources list the .inx extension as FoxBase file extension. It could be true for old 8 bit FoxBase only. More probable is IBM's Rational Rose database.

This seems to be a good resource for file extension seekers...
http://file-extension.net/seeker/file_extension_inx

There are foxpro as well as foxbase executables on the old system.  I've attached "recipe.zip" which is a zipped folder with recipe.txt inside.  Rename recipe.txt to recipe.inx and you have what I'm trying to get data out of.

I tried the suggestion of downloading the VFP ODBC driver but it doesn't seem to want to recognize the file.

Thanks

This really looks like an index file. It probably contains data from one column of appropriate DBF file. Do you have RECIPE.DBF ?

This does not look like a FoxPro file to me.

Even if it is really a DBF with another extention you can open it in FoxPro using USE recipe.inx but it's not.

No, it is definitely not a data file but index only. It should be possible to extract data for one column from this file which is not what Craig needs.

As I wrote above the .inx file is listed as FoxBase index (and FoxPro somewhere - which is nonsense) on the web.

To retrieve data the DBF file will be necessary.

These are definitely the data files for the application.  It is possible that because I saw foxpro and foxbase installed on the PC that I assumed that it was written in foxpro and it is in fact some proprietary database written by the company that wrote the application.  The application is rst2000 by Oatman & Associates and is circa '95 or '96.

The application is DOS based and I have checked all of the dos batch files that run the app and the only files that are backed up when running the complete data backup are these .inx files.  These files are also the only files that have changed on the PC since the late 90's so they have got to be the data files.  

I'm attempting to bring the old machine back online to make sure there wasn't an additional partition that was missed when the date and applications were copied off.  

It is also possible, though I don't think likely, that these are some type of cobol database; I did find one batch file that referenced some cobol code.

If I do find any other data files, I will post one or more of them here.

Thanks

I just pulled that drive up again and physically verified that there is not an additional missed partition or any missed directories.  The only files that have changed on that entire drive are the inx files that are listed.  There are dbf files under the foxpro directory but they have not changed since the early 1990's.  There are also some files under the foxbase directory, but they also have not changed since the early 1990's.

Any more suggestions?

Thanks

You still need the DBF to use the INX files. An index does only work with a DBF. What could be possible is, that that old Fox version simply had a bug not updating file dates. The question is not the file data of the DBFs but if they grew larger. I think you can't say so unless you have at least two versions of these folders.

Could it also be Clipper? Couldn't you simply ask http://www.rloatman.com/ directly?

Bye, Olaf.

I went to that website; they are an executive protection outfit in Maryland.  The company that wrote this software was out of Ontario and I've been unable to find any reference to them.  I have verified that the software is written in cobol at least the launching application is "runcobol" and all of the application files have .cob extensions.

The other reason why I'm doubting that the .dbf under the foxpro and foxbase directories are what I'm looking for is that these files are very small; the largest file is only 245kb.   The inx files are a factor of 10 larger.

Is it possible that these are some type of cobol database files?  I have zero experience in cobol.

Thanks,

Olaf,  R.L. Oatman & Associates, Inc., headquartered in Towson, Maryland, since 1989, specializes in risk assessments, executive protection training and executive protection services for the corporate, government and private sectors.

Do you think they started as programmers? Why not.

Craig: You should definitely focus on DBF files. The newer date on .inx files could be caused by reindexing, but the 5 years difference is probabbly too much. If it is inventory system then I would suppose same date for both DBFs and indexes.

I know nothing about FoxBase created in 1984 (I have started on dBase II in 1987) but I am still searching.

The FoxPro is here since 1989. Even FoxBase+ did not use .inx indexes, so your folders marked as FoxPro should not contain them. But I have no idea why you have both foxbase and foxpro folders on your computer. Newer versions maybe?

The last possibility is a different system which we cannot recognize.

The size of .inx files is much larger because they contain many free blocks (you may see the compression ration in the ZIP file). This is obvious when updating data and index contents become fragmented and not properly balanced.

Cobol programmers are either retired or McDonald's employees now :-) Fox programmers still have 10 more years... :-)

Looking at the Cobol specifications, YES it uses .INX indexes, .DAT are data files, and Cobol is a base for IBM's Rational database. So, you should look for .DAT files. If you provide a sample of a .DAT file we could help more.

.COB files are compiled Cobol sources which are stored in .CBL

Some tools are able to convert Cobol data:
http://www.netcobol.com/products/Fujitsu-Data-Converter-for-Windows/overview

This link contains discussion about Cobol data conversions and formats: http://www.tek-tips.com/viewthread.cfm?qid=1508458&page=1

This is also interesting:
http://downloads.microfocus.com/liant/download/pdf/CnvGuide.pdf

At any rate I will give you a solution.

A database files (now called table) back in the old days you could see the data clearly in them. They have a header back at the beginning of the file.

You can cut the header out and import the file in Excel (using fixed width) or by using FoxPro

APPEND FROM <dbffile> TYPE SDF
You need to create a cursor with the fields as defined in the old table

Like this
CREATE CURSOR client (code C(5), name C(50))
APPEND FROM <dbffile> TYPE SDF

Cyril, if you download Recipe.zip, unzip it and take a look at it, you clearly see, that you don't see clearly the data, it's not DBF format definately, as in a DBF you would have a short header and afterwards the records, each a fixed length, like SDF type, but only equal to SDF if fieldss are all text type or numeric N(x) fields, otherwise you'd have binary data in between, eg int fields in 4 bytes each.

I'd still recommend looking into the dbfs, even though they didn't change regarding theri file date and their size is low.
You'll never know what's inside there, if you don't take a peek. You can search for explanaitions, why file dates never changed later, if the valuable data is in there.

Bye, Olaf.

Install and run FileMon from http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx. Then run your application and check which files it opens.

I'm pretty sure that filemon will only work on a windows based machine and this application is running on a DOS machine.

I have verified that these are cobol based files.  There are also no .dat, .dbf files that are located anywhere but in the FoxPro and FoxBase directories which I have verified have nothing to do with this (they are left over from another piece of software that had been running on this machine).

So, I'm fairly certain that the INX files is all I've got to work with.  Any suggestions on how I can read these?

Should we understand your comment as the Cobol application is still ready to run on DOS machine? Does it have some "Data export option"? Does it work in Command window on WXP?

If you cannot use Filemon, the INTRSPY.EXE should work for you. It is described in Schulman's Undocumented DOS book (ISBN 0-201-57064-5) and the program itself is available e.g. here: http://www.woodmann.com/RCE-CD-SITES/Library/+ORC/Orc%20pac%202/  in FILEZ.ZIP (the lagality of above file source is on your own, I am just presenting Google search result)

The book is still available among used books but no info about included diskette exists (maine is 5 1/4" :-).

I also cannot avoid the possibility of standalone INX files. To read them is easy BUT to understand is not so easy... You may look at them using e.g. Notepad but some Hex editor is better and you'll see following:

They seems to be organized in 512 B blocks (typical for indexes). Block markers are FCFF, FDFF, FEFF. Some values look like data BUT their meaning is not clear.  Some values look like pointers inside the file BUT they obviously points to empty blocks...

This will be long way with 15 years old inventory at the end.

yes, the cobol application is currently running on a dos machine and is still used.  that machine is about 14 years old and we are moving to an inventory system that came with our SQL based accounting system.  We were hoping to export the part #'s from the old inventory system so that we would not have to re-key those values in.  We are actually not concerned about the actual inventory data, just the part #'s.

I've managed to find a former cobol programmer who is going to take a quick look and give me an estimate of what it would cost for him to export the data to a flat file format that I can then manipulate with excel or similar.  Once I'm there it will be a simple process (relatively speaking) to import the data that I need into SQL.

Thanks

Perfect! The Cobol programmer could help. Please ask him for details about files used in Cobol it could be useful for others also. I am interested if data are stored just in INX files or if it uses DAT files also. Thanks.

Cobol programmer indicated that it would not be cost effective to convert the data into a readable format.

I think CraigRuss (author) answered the question but the discussion should not be deleted.