On 2010 Jun 22, at 8:32, Winfried Huslik wrote:

> Richard,
> 
>> One	Calculation	Indexed, = 1
> 
> I would strongly advice to refrain from the One = One relationships. These are relicts from the pre FileMaker 7 era. They tend to slow down operations significantly. If at all necessary use the "|X|" predicate, where you can use any two fields that already exist.

I do indeed use the "x" relator rather than the "=" relator, I just choose to always apply it to the "One" fields, which are always there, at the top of the field list, where I can find them easily. Indeed, much of the virtue of having standard fields (with standard headers) is so I can quickly locate what I'm after when building a database.

Besides, I often have other uses for a field that's guaranteed to have a check in the checkbox, so "One" turns out to be quite a versatile performer for me. (It's also the top item on every file's inventory of value lists.)

> I do not see a reason why every table should be linked to every other table. Use only links that have a real purpose.

As I said, I use the "F" table to store, among other things, the default values to be entered in newly created records in OTHER tables. Having a link between "F" and every other table means I can simply take it for granted when creating a new field that REQUIRES a default entry that I can create the default field in "F", knowing that I've already provided the necessary inter-table connection.

I also use "F" to store the table name, layout number, and record number of any place I want to be able to return to quickly after gallivanting off to some other part of the database to accomplish some quick task like checking how many people share the surname of the current record, and that pretty much requires me to be able to do so from everywhere.

> Use of Globals for storing constant values is not recommended since they loose their content when cloned or recovered.

True indeed, and something I discovered the hard way. Thus I am careful when creating fields for the 1 and only record I have in the "F" table to avoid Global storage for fields where I want ANY user to be able to change the value for ALL users, but to employ it for those cases where different users need their own personalized version of that particular field.

>> Table	Calculation	Unstored, = Get ( LayoutTableName )
>> Layout	Calculation	Unstored, = Get ( LayoutName )
> 
> These unstored calculations bring no advantage over the function call as such. Use only where needed.

Since I display these fields at the top right corner of all my output layouts, it's easier to just have a short name for them ready to rock'n'roll when I get there. It makes it much easier when I'm doing phone support to have the table and layout displayed so I can ask the user which screen he or she is looking at. So I DO use them where needed, which is pretty much everywhere.

>> --- PASSTHRUS ---	Text	Global
>>  (Note: calculation fields that assemble data fields from this table for use in other tables)
> 
> These can be avoided all together by setting up the relation graph accordingly.

But I don't WANT to avoid them. For example, I have various fields for name components ("Name Title", "Name Pers", "Name Mid", "Name Fam", "Name Ext", and "Name Nick") and I want to assemble them in various different ways for different purposes. This requires calculation fields that operate on the name components. It's easiest to just have ONE calculation field for, say, "Name Full", with the result available in the table where all the components exist, and then refer to that field from all the other tables that need to use it. And having these calculated results readily visible under the "PASSTHRUS" heading makes it easier to find them when I need to.

>> BeSeq	Number	Indexed, Auto-Enter Serial, Can't Modify Auto, Always Validate, Required Value, Unique, Numeric Only
>> 
> 
> Auto-enter serial numbers require special care when updating tables or importing new data. I personally use an otherwise meaningless number, created as an auto-enter calculation:
> 	uid = GetAsNumber ( GetAsNumber ( Get ( CurrentTimeStamp ) ) & Right ("0000" & Get ( RecordID ) ; 5) )
> This way I never have to think about that serial number again. There are others, more complicated calculations floating around, but these seem overkill to me.

I don't see how this works any better for importing data than just using a straight auto-entered serial number. What am I missing?