Such measures typically get you 10-30% in size reduction (30% only in really lousy designs...), so the benefit is marginal. You might check the keys usually used - if you can standardize on integer keys instead of long strings, these are used again in rushmored access and can save substantial time if filtering takes longer than reading the filtered data set.

HTH

thomas

>I support an application that is multi-user and designed fairly poorly. Not only are the detail tables populated with a ton of data that can be access from other tables, 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. As these files get over 10 megs in size, performance is seriously degraded. I don't have the time to re-engineer the whole app, but I do want to try to reduce the physical size of the files as much as I can.
>
>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?
>
>Thanks,
>
>Randy