>Hi Kevin;
>>
>>No relationships, no triggers and only 2 small stored procedures are in the DBC.
>>
>
>Sounds reasonable.. If:
>
>Opening 9 Foxpro for dos tables - 0.768s
>Opening 11 VFP Tables - 1.508s
>
>
>
>
>And, VFP's tables will take much time for:
>
>Rushmore's setup (In your case. I believe, here is the guilty. But, don't punish him right now, he only makes this to increase considerably as any other database the time of INS, UPD and QUERY) :))
>.CDX's setup
>.DBC's setup (The proportion of the increase of the time won't be directly associated to the amount of codes in the stored procedures)
>
>
>Claudio

Nope ...

Sorry for juming in, but I just tested it :
In some existing more heavy function we open 69 tables at one time, and since all have a CDX, this comes to 138 physical files (no Memos).
With our 1GH server, 950Mhz client, 100Mbit network, this opens in (about) 1.267 secs, but knowing that the according diskblocks to load will already have been cached at the server (this can't be cached at the client !). This is for the Dos-app and the Win app just the same (so Win is not faster as I stated earlier, but for sure not more slow too).

Again I note that there is a 4,000 line function doing this with a huge amount of overhead. How much I can only guess. Note too, that the 69 files are spread over several directories and much overhead will be there in finding out whether the files exist, as is kinda same with the auto-atachment of indexes (the open-routine just "finds out" whether a CDX exists, and if yes, opens that too). My guess : when the overhead wouldn't be there, I estimate it will come down to 0.5 sec or so.

BTW, note that some things can be done rather wrongly here, like having a (Set)Path active, and opening the files via the path, or doing a File() (our looking for the CDX); the File() will just look all over the path, no matter whether your file is in the current dir.

So believe it or not, around 1 sec for 69 logical files is reachable easily, as long as all is done right.

HTH,