It sounds like you're confusing a table with a table occurrence (which is very easy to do; FileMaker isn't completely consistent about the two terms). The objects under the Table tab in the Manage Database dialog are tables; the little boxes connected by relationships on the Relationships tab are table occurrences. They're like aliases that point back to the parent table.
Which brings up the concept of context. This is an extremely important concept in FileMaker. It refers to the table occurrence any given calculation or object is attached to. No calculation, object, layout, etc., is attached to a table in FileMaker. They all attach to a table occurrence (TO), which then points back to the actual table. Think of it in layers.
Table <--- TO <--- Object / Layout / Calculation
Because every layout is based on a TO, it gives FileMaker a path through the Relationships Graph to resolve any related data. This is also true of all the calculations in the Manage Database dialog. You can see this from the "Evaluate this calculation from the context of" pull-down at the top of the calculation dialog:
Think of the Graph as stepping stones through a river. FileMaker will start on whatever TO on which you're currently standing, and hop from TO to TO to resolve the calculation. (Sometimes it can't, because the TOs aren't related, and then you'll get an error.)
Now, in your case, it sounds like you deleted some TOs and various objects and calculations were relying on them. When that happens, FileMaker loses the internal pointers that tell it what path through the Relationships Graph to take to resolve the item. So, it "runs home to Momma" and asks the developer to fix it.
There's another wrinkle that pops up here. Whenever you create a table, FileMaker automatically creates a TO for that table. That TO becomes the default TO for all calculations based on that table in the Manage Database dialog. So if you were to delete that one, you've basically cut the stump out from under the tree.
Which brings us to your question: How do I fix it? Well, you have to repoint those calculations back to the correct TO. That means manually going in and telling FileMaker which TO to use for each calculation. This is usually a painful process. As you've already discovered, if you try to repoint the calculation to a TO different from the parent / default, FileMaker will insert the TO into the calculation (this is called the "fully qualified" field name). That means it's a TO that's related to, but on, not the current TO.
Hopefully, all this makes sense. But basically, you pulled the stepping stone out from under your calculations, so FileMaker is moving to the next stepping stone you point it to.
A full resolution of the problem would require reverting to a backup. This is why it's usually not a good idea to delete a TO until you're certain it's not actually being used for anything.
good advice, as always, Mike. At first, I was thinking perhaps the 'table' was really the LAYOUT displaying the data and not necessarily the T.O. But given the alert dialog and/or "missing" elements, it would be the T.O. that is lost. Adding these back to the RG (relationship graph) would bring them "back" AND the layouts may need some cleanup to re-attach those T.O.s
p.s. for OP, the mantra is "backup, Backup, BACKUP" (always have a backup and know how to get to it!)
Backup is a good idea. But FileMaker should never tell „you can delete your current table and will not loose your tables and your data“ if the data is still there but no way to use and see it anymore. I know, that the visible FileMaker structures (tables, fields) are adressed by internal IDs (you call it TO). Mike says, relinking the TOs is the solution, but what the tool for relinking?
The tool for relinking is open up each object and pointing it to the correct TO. In other words, you have to establish the links manually, just like when you first created the object.
As an aside, deleting any structure from a database is a risky operation. They're hard to get back, in many cases. So not only should you have backups, you should be certain that the object really is deprecated before you rip it out.
I use a tool called BaseElements, from Goya, to help me determine what objects are really unused. But you can just generate a Database Design Report (DDR) and search it for any references to the object you want to delete before you do it.
Mike, that’s exactly what I already did. I made new fields, the same like before, this generated a new table. The browser said for every field “<table missing>”. I switched to the database manager to see in calculations “from <unknown>” and “<fields missing>”. I double clicked the calculations and restored the links. But the links linked not to xxxFieldName but to TableName::xxxFieldName. And how can I relink text and image fields to the original content? Double clicking those fields only opens some options for this field. Meanwhile I’ll have a look for Goya BaseElements …
PS: The calculation fields are not important. I need only access to the content from ONE text field. The database is OK. I can save as copy, restore with the FileMaker menu and so on. The physical size of all these databases is right, but I can’t see the content.
Creating new fields doesn’t generate a new table. I don’t think you’re understanding what’s happening here. Let’s try again.
Each layout is based on a TO. You can see this from the Layout Setup dialog. When you delete a TO, the layout loses its underlying foundation, so it reverts to “table missing”. That means it doesn’t have a TO it’s pointing to any more. You have to establish which TO it’s pointing to in the Layout Setup dialog.
Now, in the calculation dialog, you have apparently deleted the base TO for each table - the one FileMaker creates when it creates the new table. When you do that, then FileMaker has to change which TO to use as the basis for the calculation.
The links that read, “TableName::FieldName” just mean that’s the occurrence from which FileMaker is drawing its information. For example, if you have two TOs for a table, say, “Table” and “Table 2” (which would be the defaults), “Table::FieldName” means the reference point is the TO called “Table”. “Table 2::FieldName” means it’s referencing the “Table 2” TO. But both references point back to the same table, so you haven't lost any data, nor will the data be any different in one TO vs. another.
You can rename a table occurrence to a different name just by double-clicking it. (If it’s really bothering you that it’s not just called “Table”.) But the important point to understand is that whatever TO you’re referencing is the context for the calculation. It will affect how the calculation is resolved.
Image and text fields can be repointed by using the pull-down in the dialog that opens up when you double-click them. Here's some screen shots:
OK, we are talking about the same, but I used the wrong terms. What I mean is, I deleted the last TO. My tables and my content are still there. Now I recreated all fields (same name, same calculations, same order). This created a new TO. But this TO is NOT the original TO. The new TO doesn't appear as „Current Table ("TableName"). the new TO appears under "Unrelated Tables". I can link my fields in layout mode to these fields, but the content doesn't appear. In Layout is every field connected to “::FieldNameXY“ (should be "FieldNameXY"). In browse mode every field tells <unrelated table> and doesn't show content. What I think is, FileMaker doesn't connect a new field "FieldNameXY" to the content of an former field "FieldNameXY". FM connects an old FieldNameXY to content e.g. FieldContentID2341. When I recreate a field FieldNameXY, FM doesn't know anything about thew former connection and creates a new e.g. FieldContentID5543. That's what I think. My problem is: How can I tell FM, that TableName ist now the Current Table. Or how can I link the TO to the database content? Linking the field in layout to the field in table is not my problem.
I would suggest that you grab the FileMaker Training series and work through each lesson. If nothing else it will help you to communicate more effectivly in this forum
Bottom line is that a layout, among other things, is based on a TO, not a Table. Linking a layout, or calculation, or whatnot to a Table Occurrence is the thing, and the only thing, that makes it the "current table". FM doesn't designate one particular table occurrence as your "current", and there's no way to make it "current" except to specify it as the context for a layout or calculation.
If you've deleted the TO that was linked to a variety of things, those things are then linked to nothing. You'll need to create a new TO (even if it's from the same table, with the same name) and link it up in the old TO's place. There's no other way to "explain" to FM that you mean for this TO to be the default, or main, or current, table.
It sounds like you created the new TO, but didn't re-establish the relationships between it and the other TOs. You're going to have to connect them back together again.
coherentkris: I'm working with FileMaker since the first version and made many big databases. I would suggest that you try hard not to be such an arrogant idiot, grab an book about human behaviour and work through each lesson of kindness. Sorry that I'm not firm with the english terms, cause I’m using a german version of FM. Nowhere is written, that this forum is only for english speaking natives.
"It sounds like you created the new TO, but didn't re-establish the relationships between it and the other TOs. You're going to have to connect them back together again." --- Absolutely right! But there is only one TO (the new one) and no possibility to relink this TO to the database content. The FM support escalated this problem already through all german instances to the HQ in USA. I know, it's not trivial.
For better understanding 3 images:
Thanks all for your help and ideas. I've just found the solution. It's not possible to let reappear the database content only with recreating the TO. All layouts stay empty in browse mode. The solution is, also to make a NEW layout. All content shows up.