For your information, I was in a somewhat similar position myself not so long ago. I took over an old application which used a lot of idx's. Since this caused problems, I had to get rid of all the idx files. I fixed this easily in a few steps:

• The first thing, is to find out which table uses an idx or more, and write down the their name(s) and index key(s).


• Add index tags for every table which uses an idx or more


• Search for "order" using GoFish, and change these lines if necessary


• Search for "Set index to" using GoFish, and change these lines if necessary


• Search for "Index on" using GoFish, and change these lines if necessary


• Delete all the idx files

As always, don't forget to make a backup first, just in case...!

Much to my surprise, it didn't take me more than a few minutes to do the whole conversion, on a very large application. Thanks to GoFish.

>Thanks Paul, that's the direction it seems that I'm going to take but interesting found thru googling that Sybase ADVANTAGE has a odbc driver that supports xbase and idx, interesting!
>
>
>>>Thanks for the response Thomas, the files actually have a CDX as well but can't get rid of the IDX for now, it's a system gone bad basically, over the years they never updated, they just added stuff on top. So basically we also need to have the IDX open, one developer already researched and couldn't make it work and started creating the workaround and it was handed to me, unfortunately the deadline is almost up so don't have the usual period for trial and error/testing, so I will continue working on his workaround unless I know for sure that someone has been able to read and update foxpro data that contains an "IDX".
>>>
>>>
>>
>>In this case you're probably better off with the COM component solution. If this is a possible multithreaded situation, I'm almost always happier just wrapping the calls in a lock. It's easy and avoids odd issues.