Changing table name

[Mark Welch]

I'm continuing to have problems when I seek to rename a table. Specifically, I create a table with a name like "test_table" during early testing. Then, after I rename the table using "Manage Database," it simply becomes completely invisible within FileMaker; when I try to create a new layout to reference the table, it does not appear in the list of available tables.

This is very, very frustrating, especially since it has happened multiple times and every time the only solution is to start over from scratch, with a completely new database file, and manually re-key all the scripts, data, etc.

I am sure that I'm missing something obvious, since I see many references within this forum to renaming tables. (I also can't find any way to rename a layout.)

[RalphL]

Layouts are based on Table Occurrences (TO's). Go to the Relational Graph and rename the TO.

Edited January 3, 2009 by Guest

[aldipalo]

First, to rename a layout go into Layout Mode. Right click on an open area of the layout and change the name. You can also click Layouts in the menu bar then click Layout Setup and change the name.

Second,

Specifically, I create a table with a name like "test_table" during early testing. Then, after I rename the table using "Manage Database," it simply becomes completely invisible within FileMaker; when I try to create a new layout to reference the table, it does not appear in the list of available tables.

How are you specifically doing this? You should go to Manage Database/Tables, highlight the table you want to change, change the name in the box on the bottom of the screen then click the "Change" button. FM should take care of the rest.

Also, have you checked to see if the new table is in your relationship graph?

[IdealData]

There is a subtlety in FM that needs some explanation.

The names of TABLES are used as the default name for each new table occurrence (TO) in the relationships graph. You can have many TOs for the same TABLE

By example, a CLIENT and SUPPLIER record will share the fields generally, but you don't need to have 2 TABLES, you could just have CONTACTS as your TABLE NAME.

In the relationships graph you would have 2 TOs - CLIENTS and SUPPLIERS, both of which are based on the same original TABLE - CONTACTS.

From there on all your field definitions, layouts, scripts etc would refer to the CLIENT or SUPPLIER, but in the background the data is only stored in the CONTACTS table.

I'm not saying you should necessarily design this way, but it is purely to help you understand the difference between TABLES and TOs you see in the graph. Hopefully this will explain to you that renaming TABLES cannot rename TOs - and in my example would be quite undesirable.

[bruceR]

I'm continuing to have problems when I seek to rename a table. Specifically, I create a table with a name like "test_table" during early testing. Then, after I rename the table using "Manage Database," it simply becomes completely invisible within FileMaker; when I try to create a new layout to reference the table, it does not appear in the list of available tables.

This is very, very frustrating, especially since it has happened multiple times and every time the only solution is to start over from scratch, with a completely new database file, and manually re-key all the scripts, data, etc.

I am sure that I'm missing something obvious, since I see many references within this forum to renaming tables. (I also can't find any way to rename a layout.)

Could you please submit simple example files?

Your problem description makes no sense and as you note, doesn't match anybody's experience. You must be leaving something out of the description.

I have attached example files where the tables have been renamed with no problem.

Archive.zip

[bruceR]

I'm continuing to have problems when I seek to rename a table. Specifically, I create a table with a name like "test_table" during early testing. Then, after I rename the table using "Manage Database," it simply becomes completely invisible within FileMaker; when I try to create a new layout to reference the table, it does not appear in the list of available tables.

This is very, very frustrating, especially since it has happened multiple times and every time the only solution is to start over from scratch, with a completely new database file, and manually re-key all the scripts, data, etc.

I am sure that I'm missing something obvious...

OK, I think I'm beginning to get your point.

Yes, you're missing something; no, it's not exactly obvious.

It is important but it is one of the trickier bits of the Filemaker relation model.

I'm going to try my way of saying some of the things that others have already mentioned.

1. The relationship graph is the foundation for everything.

2. Objects on the relationship graph are named.

3. Named objects on the relationship graph are called Table Occurrences (TO)

4. There is no such thing as a list of available tables.

There is a list of available TOs. In a sense, if it ain't on the graph, it doesn't exist. See item 1.

5. A Table Occurrence is like an alias or shortcut or pointer. It is a symbol that represents the table. The table being represented is often called the "base table".

6. There can be more than one TO for a given base table.

7. Because a base table and a TO are two different things, the name of a base table and the name of a TO are two different things. They *can* be the same but they do not have to be. Renaming one does not necessarily rename the other.

8. Though you can have multiple TOs for one base table, all TO names must be unique. At first glance the idea of having multiple symbolic objects representing only one base object may seem confusing. However, it is very useful and very powerful.

It takes some effort, but once you finally get it you will realize how powerful the symbolic nature of the TO concept is.

Let's say you build a complex solution with lots of script and calcs and relations, and one of the TO objects is CONTACTS. You decide that you are going to put the Contacts table in a different physical file.

You do this, and then you go to your graph and change each of the CONTACT table occurrences so that they "point to" the new file. Done. Everything - all your layouts and scripts now continue to work exactly as before.

It's all about (and pretty much ONLY about) the graph.

[comment]

4. There is no such thing as a list of available tables.

Well, there's that thing under the "Tables" tab that shows a list of all tables (in the current file, at least) and their TO's.

This, BTW, is a rerun:

http://fmforums.com/forum/showtopic.php?tid/199158/post/308342/#308342

[bruceR]

Well, there's that thing under the "Tables" tab that shows a list of all tables (in the current file, at least) and their TO's.

This, BTW, is a rerun:

http://fmforums.com/forum/showtopic.php?tid/199158/post/308342/#308342

But those are not available tables. By design, there is NOTHING you can do with that list except for documenting design info about contents of a file.

[comment]

There are a few things you CAN do there - most notably, you can rename a table.

I don't think this is going anywhere until Mark tells us exactly what he did when he "renamed a table".

[aldipalo]

I create a table with a name like "test_table" during early testing. Then, after I rename the table using "Manage Database,"

IMHO, it appeared to me that Mark starts off with a non-descriptive name for his application rather than having a regular naming convention. So, instead of naming his application "Contact Manager" or "Inventory System" he just starts off with "Test_Table." Once he has his structure in place he looks to start changing the table names and this is what is getting him in trouble.

[comment]

I don't see anything wrong with the process you describe. I do this all the time (all the demos I post here in the forums start as a copy of a template file), and it hasn't got me into any trouble.

[aldipalo]

Ahh, but you are a Guru not a beginner.

We tend to have lapses in memory and good judgment. When actually doing a test I don't see a problem either. All I'm saying is when you start building an application with Test_Table1 and Test_Table2, blah, blah and you are a noobie you are uping your chances of forgetting your way and you will have something go wrong. I just think it is better to run a few tests and then go back and start your app with a proper naming convention.

Anyway, until Mark gives us a step by step of what he has done it is just conjecture.

[comment]

Ah, but Filemaker is quite helpful in this: whenever you rename a table, all the references to it update automatically to match. I could understand if this was about renaming files, and losing file references - but he specifically said he was renaming a table in 'Manage Database'. I don't see how even a novice could get into trouble doing that.

OK, enough guessing.