Are there any drawbacks to creating a second occurrence of a table?  I have hunted around through documentation and help and I can't find a concise discussion of what the negative impacts of it might be.

Basically; no. But let's be sure you understand what "second occurrence of a table" means. That means a table occurrence on the graph. It does NOT mean defining a new identical table, having duplicate records.

Creating another table occurrence of an existing table is often an absolute necessity. An example would be to have the "same" table relate to another via a different match field so it can be used for a diffent purpose. This process can also avoid the dreaded "circular logic" error. There is no load penalty as far as I can tell.

Hi Michele,

 

I would say there is small penalty for extra table occurrences (anchor-buoy is prime example).   FM must resolve them all so the more you have, the slower if there are auto-enters, imports, or calculations involved.  The other penalty is cluttered graph so it is good to add a table occurrence only if absolutely necessary.

 

If you can give a specific example, we might be able to help you find alternative approach, if applicable. :-)

Another drawback of multiple table occurrences is extra scrolling through table occurrence popups and increased length of table occurrence names to keep them all straight (also meaning they can become too long to read such as in export dialogs).  Using multiple table occurrences is fine; after all, that is their purpose but add them only after careful thought of the alternatives and consequences.  They are, as with calculations, over-used ... many times added because it is the quick and easy way out instead of the best choice.

Are there any drawbacks to creating a second occurrence of a table?

 

Compared to what?

Thanks, everyone.  I am aware that it's a second occurrence and not an actual copy of the table, and after investigating various other options -- or rather the lack thereof -- I think this is the right way to go in this case.  This will be the first time in seven years we've had to do this in our database, so I'm actual kind of pleased that our design hasn't needed it until now

This will be the first time in seven years we've had to do this in our database, so I'm actual kind of pleased that our design hasn't needed it until now

 

Substitute …

“in our database” with “while driving our car” …

“design” with “style of driving”, and …

“it” (another table occurrence) with “shifting into second gear” …

To me, the lack of extra table occurrences indicates that you are using an entity-style design which is very efficient and clean and it is easy to place fields or find data up and down the line (bi-directional flow of data).  That is a good thing.

 

Extra table occurrences are only necessary when the functionality for user interaction or some reporting requires it.  Sometimes it takes more thinking through of what is needed rather than just simply placing another table occurrence ... good on you, Michele, for keeping your system lean.