In the old days of data storage, much effort was put into defining the lengths of Text fields as that allowed for fast access and minimal storage waste. FMP seems to make no mention of it, other than as a validation criteria. Given minimal hard disks are 40GB these days, it does seem to make sense to ignore that complexity. However, the basic docs never mention speed or efficiency at all... and I *know* those remain issues... there's always someone needing a bigger database. So, there are some things I wonder about...

If you specify a field to have max length, does that result in increased efficiency or reduced space consumption?

If you store a Boolean as either "Y" or "N", how much space is that field consuming?

Are there things you can do that will result in faster or slower performance in accessing, searching, and editing data?

What are the performance implications of regular expressions and the like?

Thanks. If there are papers or manuals describing these details, feel free to just point me to them... I haven't found any mention of it.

FileMaker obviously uses some mechanism to dynamically assign storage to text fields. Creating a text field doesn't result in the reservation of the 64K max size. If this is true, for speed/efficiency purposes, fewer and smaller fields are better. Fewer fields per file are better. Enabling indexing on the minimum number of fields is better. Not placing summary fields on other than report layouts is faster.

-bd