>>Would not ADIR() have the same problem of slow reading all the files into an array that FILE() has?
>
>Probably even worse, since it would be reading every file's data into the array, rather than just returning .T. once it was found.
>
>The problem is inherently the network infrastructure. If the server cannot get the listing to the machine quickly, it doesn't matter what software is doing to analyze the data. Without knowing your setup, consider the following:
>1. Faster NIC in the server (10BT->10/100BT->1000SX)
>2. Faster NIC in the workstation (10/100BT should suffice)
>3. Dedicated path from workstation to server (via a network Switch)
>4. More server memory = more directory information cached on server
>4a. Faster disk access in server (performance boost may be subtle though)
>5. Dedicated server for picture storage (80K files? you can justify it)
>6. Depending on the app that generates the pictures, you could store them in a general field of a VFP table indexed on the picture name field. (or maybe the archived/approved pictures could be stored this way?)
>
>1-3 = faster communication from server to workstation (relatively inexpensive to implement)
>4&5 = faster performance at the server (possible small return for large $$ investment)
>6 = complete redesign of data storage (very radical)

Thanks for the input, so far we have in place 1-4a now. I think my proposal to the network and draftmen/draftwomen is to segment the drawings up so that there would be no more than say 500 per directory. Run a test and see if that helps.