Avoiding Disaster

[wamay01]

Here is something to avoid at all cost. When you create a table it creates a default relationship. If you delete a tables default relationship you will never be able to get to your data or use the table again. The warning that the program gives you when you delete a relationship only states this action will "break all items that use these tables...but will not delete the underlying tables or their data". DON'T believe it for a second. You will never be able to access your data or use the table again.

[bruceR]

Nonsense.

[Kurt Knippel]

Not true at all. What you are deleting is the relationship between one occurance of a given table and an occurance of another table. You are never touching the underlying data or tables and you can easily recreate the relationships by dragging the fields from one TO (table occurance) to another TO. Or you can delete that TO and add another one.

[Vaughan]

I offer a "deleted table occurrance recovery service" at $1,000 per hour (minimum 2 hours). Contact me off list.

[Crag]

Actually I think, when you are creating relations you aren't even REALLY touching the tables. I look at it as if they're "pointers" (to borrow a term from C) really. It's completly serparate from the data (which is a good thing). Deleting any relationship will not delete the table.

BUT, if I have found that if you delete the only reference to a table and try to access any fields (like selecting a field from that table to place in a layout) you won't see them. But this is EASY to fix. Just go into the relationship area and add the table. Simple.

[wamay01]

Actually you are all wrong. You cannot recover the underlying data. Do a simple test and try it. This was a level 2 issue at filemaker and the final response was "you are right" you cannot get to your data. When filemaker creates the default relationship it tags that relationship with a certain identifier. When you recreate the default relationship it doesn't have the same identifier. Your fields in a layout will say one of 2 things, "Unrelated Table" or "Table Missing". I notice you are all on Macs so perhaps this is an XP problem. When I get a chance I will reproduce the error on a Mac and see if I get the same results.

[DanBrill]

Vaughn -- usualy when people write LOL I'm usually pretty sceptical that they were actually laughing out loud. But this time I was LOL!

I'm using XP and I can't duplicate the behavior. I created a new file with 1 table and one text field. I entered a few records. I then went to the TOG and deleted the automatically-generated TO. Saved the changes and went back to Browse mode. Sure enough, it said the table was missing. Went back to the TOG, added a TO for the table, saved, went to Browse, directed the layout to be based on the new TO, and bingo, there was all my data, unscathed.

wamay01, can you post a description of how you made this happen? Have you updated to FM7.0v2, or are you still using v1?

Dan

[wamay01]

OK. It kills me that neither FM support or myself stumbled onto this. When I go to the layout and tell it to use the new TO it still sees the existing fields as "table missing" however I can replace the fields with themselves and I can then get to my underlying data. This sure would have worked better than recreating the entire database like I did. Thanks for the help.

[MoonShadow]

You must respecify the layout in Layout > Layout Setup and 'Show Records From.'