>>>>I'm working with an application where they author of the app is using only free tables, and idx vs cdx indexes. I understand all the issues with the free tables and not having them in a DBC -- but I've never even used IDX indexes. I'm wondering if there are any advantages or disadvantages to using IDX indexes. Thanks!
>>>
>>>HackFox3 says "In fact, the only reason to use stand-alone indexes at all is to maintain compatibility with other products or older versions that can't read compound index files."
>>>
>>>Maybe the app was developed when either of the above were true.
>>
>>That is exactly the case - it's an app that's been around a long time - it's all .prgs and .scx's - there isn't one classlib in the whole project. I'm trying to convince them that we should be using .cdx indexes instead of .idx's, so I'm trying to come up with some valid reasons why we should lol lol. This app is going to take me a couple of years to get more current.
>
>Check the file dates, it's possible that major parts of it were written before 1992 :). At least that's the year when we here started to get rid of idx files. I simply can't see how we managed to keep track of all of them back then, with 8.3 filenames seriously limiting any naming convention. That's probably the reason why we didn't write apps which would be too big - with 80 or 120 tables. And yeh we had to have reindexing routines, because there was always a chance that some routine opened some of them but not all. Which is your major selling point when pushing for cdx - no maintenance, less clutter, opens automagically and is much smaller (check for any place where the app creates those idx files, I bet it's not using the COMP clause which would force the .idx to use the Rushmore-type of compact index).
>
>That being said, I wonder whether the app, if written so old, uses much of SQL at all. If it doesn't, then it's possible that it has some tables which are there just for speed's sake, or as temporary storage - pretty much what we'd use cursors for. I remember in 1989-1992 we had many of such tables, which were gradually made redundant as we learned how to get rid of them (and of unnecessary indexes) by going with SQL.

No use of SQL - that's one of the 2 big things I notice about really old xBASE code bases. The other - somewhat related - is if the code was started under FoxBASE+ where only 10 work areas were available. That could severely limit DB normalization and force the developer to go through gyrations with intermediate results tables and a lot of SET RELATION, SET KEY etc. *shudder*. Very fragile, hard to understand and maintain.