In W2K and XP times (read: no ssd, 32Bit OS, RAM > 2GB) I had a machine park running different tasks, some xBase, some SQL based. Rule of thumb was, SQL tasks with lots of memory, xBase with less but additional RAM disks.

Those RAM disks were used to for nonstructural indices, as they were much faster than HD - they are still faster than todays SSD, but the difference is not marked enough to go to the trouble of setting up and measuring. Same reason for throw-away indices: putting them on another disk allowed much better speed, as source tables were read without moving disk heads to write out cdx, that was delegated to another device, speeding up total process.

Not a thing for a tool used in day-2-day operation, but a tiny trick to keep in mind if facing serious perf problems...

regards
thomas

>>>While improving Bin2Text I come to the index file problem.
>>>
>>>FoxBin2Prg does structural compound index files. Do you see any use in processing Nonstructural compound index or Standalone index files?
>>>I do not use this at all, and it looks rather ugly to do. So I'm just curious.
>>
>>Only sometimes, when I need such an index and don't want to disturb the structural one. But even then, it's temporary, so no maintenance except not forgetting to delete it afterwards.
>>
>>What's the point, anyway, when whatever benefits such an index can bring can be better achieved by SQL.
>
>SQL optimization? I do not work an tables anyway, but then FoxBin2Prg is a VFPX tool not made for me. :)