Hi Mike
>
>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. :)

As I am also one of the vocal MDotter's perhaps it is no surprise that the code is (together with some error handling for esoteric alias-dropping errors) is in a global _use function <g>. Re constant behaviour: this is not always guaranteed, but for my UC it nearly hapened, as I have small fast partitions cordoned of for my time-critical work on different HD's I can format before loading the data for each run. Reduces fragmentation a lot and gives better chances for reproducible measurements. Having the data consecutively in the disc sectors helps for instance reading the rushmore bitmap - there are other ways to insure that, but chances for that to happen are better on different drives.

regards

thomas