What is the canonical relationship technique for accessing global in another database?

I have a table that has several global fields that I would like to access from the layout of another table (I'm still on FMP6). There is no other relationship between these two tables.

Some kind of artificial relationship has to be constructed. What is the usual technique? I tried relating between globals fields but that doesn't seem to work. At least, I get a warning that says globals cannot be indexed so the relationship won't work.

So, what's the correct technique to use here?

The usual approach is to create a field in each file:

One_k (calculation, number indexed) = 1

Create relationships between files matching the One_k <--> One_k

This relationship is matches every record in one file to every record in the second file, giving you access to globals in another file.

I typically create a "Preferences" file (table) and relate every other table to it using this technique. I keep globals not needed for relationships in this file.

-bd

Thanks. I guess I was close. I already have a field that is used for a self relationship. The field is a number auto entered as a 1. I can see the advantages and disadvantages to this being a calculation. Being a calculation, means that imports from an existing database don't have to deal with fixing up the value. In fact it means that the field never has to be dealt with at all. Also there isn't data for every record required.

However, is a calculation going to be as fast? That's probably not a real issue for me, but it could be for a much larger database. How well will the calculation scale?

I guess I was looking for something that didn't try and realate everything to everything. Is there overhead in making that assessment by the database even though it is never used?

I guess if it is the usual technique then, FileMaker has accounted for it somehow. Otherwise they would have some other way of doing it.

Thanks for the tip!

In order to be used in a relationship, the calculation must be stored and indexed. Since it would only be recalcalculated if the fields the formula is based upon were changed (and there are none), there is no difference in performance between this stored calculation field and an autoentered number field. I've been using this techique for over 5 years in files with over 300,000 records, so I'm sure about this answer!

-bd

You can get to a global with any relationship even an invalid one (no matches in both files). In fact, using an invalid relationship is a lot faster with large record sets because FM doesn't have to resolve the related record set.