sharing a table among two solution files

[DFehrenbach]

I have a large solution file that I would like to use as the starting point for a new solution file and will be used in parallel. This is to be able to operate two similar but separate divisions of the same company. One table in the original file (Contacts), however, must be shared with the second file but all other tables should remain in their respective files.

My first thought was to take the table to be shared and create it as it's own file that can be brought into each solution as an external file, but what about the relationships, fields and scripts that are already coded in the other solutions? Is there any way to do this without going through each calculation field, script and layout in each solution to point to this new file?

[Fenton]

There should be no problem putting a table occurrence from one file into the Relationship Graph of the other file. While you define the External File Reference to the whole file, you only insert a table occurrence to one table of any given file.

If all the Contacts (and any other relevant tables) are on the graph(s) of the 2nd solution, they become partially "interface" files of the file containing the actual Contacts table.

There are other possibilities. I'm sure you've already considered and discarded keeping only one set of tables, and separating the data via a field with the division, via the interface, when possible.

Another method you may not have thought of would be the "David Graham" method of separation. Where each division would have its own table for a particular set of data (as you wish), but also a 3rd table, with all common fields (in this case almost all of them).

The "division" tables would serve almost as "virtual" tables, in that they would have their own records (important for List views and Finds), but would have very little actual data. The "central" table of each pair would have the data.

This would give you what you want, but also allow the data to be seen en masse when desired. The method could be only implemented for tables where it was desired.

It has one disadvantage, which is that most of the fields on the "division" layouts of these tables would be related, via a one-to-one relationship. Hence a little slower for Finds, etc.. But one-to-one is relatively speedy, so should be OK for most things.

Edited June 24, 2010 by Guest