Hi Thomas!

>Mike,
>>>The benefits of this approach have likely diminished as the speed of PCs and networks has greatly increased since then.
>>
>>That's for sure. That's only one reason for doing something in a counter-intuitive and non-standard way! By doing that you are simply increasing the chance that you will have data out-of-synch with the cdx. The gains are only beneficial in certain circumstances such as having few records in the file and appending many.
>
>In general I agree with the part recommending to stay "standard". Also I agree that having dbf, cdx, fpt and database files in a common subdirectory makes secondary handling (install, backup) so much easier. But FORCING those different files to be on the same physical disk is where I disagree - physically separating cdx from dbf can speed up xBase operations and the join step of SQL. Pathing those files in a dbc (with an empty default) would have been the appropriate thing to do IMHO. Tested myself around 2000 on vfp6 on very time-intensive runs, but also separation of physical disks for index and data (after separating transaction logs) can be found as a hint for SQL layout improvement in big CS-setups.

I'd agree with doing that for speed increase. The positioning of files on faster drives makes sense. I want approaches that yield constant behaviors and constant speed increases, but still be easy to incorporate. Mdot is such an example. One could alter the code that opens the tables to accommodate the cdxs being elsewhere. The append from trick only works sometimes and only if needing to append. Your suggestion would apply to all aspects of data access.

As long as the entire application made use of a standard approach to accommodate the cdx location, that sounds perfect to me. :)