Your instinct is correct. The very first TO created for a table when the table is created becomes the default for calculations created against that table.
Having only rarely run into this myself, I'm afraid I don't have a good means for fixing it. There are a couple of things you can try:
1) Move the TOs around on the graph until the one you want is put in the appropriate spot on the graph (and named appropriately). This may create more headache than it's worth, though, depending on how many joins are broken in the process.
2) ON A COPY OF THE DATABASE ONLY ... try deleting that default TO and see where FileMaker goes. I don't know what this will do, though, so again, only do this on a copy! It may end up pointing you somewhere worse.
FileMaker stores the TOs in the order they were created. Unless you can know what that is, it'll be something of a leap in the dark using method 2.
Someone smarter than I may have a better idea.
Why do you care at all? It simply does NOT matter since any record belongs to the BaseTable, regardless what TableOccurrences exist for that table.
I wonder what makes a TO less important? If it is used then it is important, if it is unused then remove it.
Winfried, normally you're such a great source of information but this isn't helpful.
It matters a great deal.
It matters, for example, when setting up calculations or lookups. In both cases the context is vital and the developer will want to know what context is the default. Of course table occurrences and relationships should be set up based on this default if the developer is going to rely on it.
Hi Winfried, thanks I appreciate your question. I'm sure as Bruce mentioned there are several reasons why this matters (obviously, or it wouldn't be needed on the calculation layout in the first place), but I'll give you an example of what I'm running into.
TO#2 - currently is set to the default
Both table occurrences are important to me, but for different purposes. And most importantly, they do not have any relationship whatsoever on my graph. So if I'm looking at my main data entry layout which shows records from TO#1, and I have a calculation like:
If (TO#2::Field = "Yes" ; "True" ; "False")
This calculation is always going to return false because there aren't any related records from TO#2. If I fix it to go back to TO#1, then it evaluates correctly.
I kept running into calculations that were producing unexpected results, and it took me some time to figure out it's because they were all being evaluated from the context of the wrong TO.
I appreciate your input and everyone's help on this!
1 of 1 people found this helpful
You are certainly right as far as it concerns the definition of calculations.
I admittedly wasn't very exhaustive as I've just focused on "default for new records created in that table" and ignored the second part which obviously was the real question.
In an attempt to be helpful I may point to two functions that may help to spot the "main" TO:
TableIDs ( Get ( FileName ) )
TableNames ( Get ( FileName ) )
where the lower IDs or the first listed names are the default TOs.
One may rename these to the BaseTableName and use them henceforth as default. In case "unimportant" TOs come first, these must be removed and created again (which causes them to get a higher ID).
Excellent! Thanks, Winfried; that was the piece I was missing.