>> but the app is installed from the server with a link at each desktop. So as tables are needed, they are opened up over a network share.

Could you explain this a little more. A multiuser app will normally be installed on a network and files are opened over the network. With today's zippy networks this is generally fast. Perhaps I'm missing your meaning.

>I have started by dropping fields in the detail that I can join from other tables. I am reducing the size of text files where I don't need them to be as large. I have a few questions. If a field does not contain any data, does it still take up the same amount of size as if it did just based on the definition of the table? I have an item description field that can be overridden at the time that item is used on an order. The application stores that field in the table regardless of whether or not it is overridden. I can certainly change the app to only store the ones that are overridden, but does that get me anywhere? Also, I have numeric fields that are 12,2 that probably only need to be 9,2. Will that save any space?

I think you got the answers to the above questions. I'd add that VFP tries to get all the indexes loaded into RAM, so having indexes that aren't unnecessarily large is good. Of course, you need to have the proper indexes to get the most from Rushmore, but indexes for long character fields can make an index get quite large. If the fields are longer than they really need to be, then cutting their size - assuming they are indexed fields - will cut the size of the index itself.