You normally want to avoid data duplication of the sort you are describing. What is the reason you want two identical tables?
Do you want exactly one set of data to exist or copies in each separate file? Option 1 is easy. Option 2 can be quite difficult depending on how your data is structured and used.
Describe your reasons for setting up this type of system. That'll answer the above question and also may allow someone to suggest a completely different approach if applicable.
Thanks for the quick responses. I don't necessarily need to duplicate the data. What I am trying to do is create multiple individual databases and then have one database that is tied to all of these separate databases to be able to view and enter data from while also having the reciprocal ability to enter data into one of the "siloed" databases and have this data reflected in the main databse. I know this should be fairly straight forward but I can't seem to relate them and have them synch up.
Thanks again for the rapid replys - let me know if the above still is not clear and I will try again to explain in a more lucid manner :smileyhappy:
Two options depending on what you want to do:
Option 1: Place a single copy of your DB on one computer and use filemaker, filemaker server or Filemaker server advanced to open it. LAN based users would use the filemaker pro application on their computer to link to the Database using "open remote". If you published the database to the web, users could link to the database using their web browser application.
Option2: (You really want seperate databases).
Create one database as the place where all your tables are defined. In subsequent database files establish a remote data source link to selected tables in the first file. To do this, you'd create a new table occurrence in Manage | Database | Relationships and select a table in the first file as the TO's source table.
I think I understand.
Create your database which everyone is going to share. Let's call it the common database. The common database would be placed somwhere where it can be shared: FileMaker Server; FileMaker Server Advanced; or FileMaker Pro or FileMaker Pro Advanced set to share in a peer to peer set-up.
Create your siloed databases. Include the common database table occurences. Your siloed tables are tied to the common database. Make your layouts based on your common table occurences. Add portals to your siloed tables in those layouts.
With this set-up, everyone will be able to see and edit the common table information. Only the users of the individual siloed databases will also see and be able to edit only their siloed tables information.
Is this the type of solution you are looking for?
Thanks again to both of you for the help. Phil, I went with option 2 of your suggestion. This works except now in my "siloed" table none of my data from my main table is viewable. The amount of records matches the amount of records in my main table and when I delete or add a record in either database the record count changes accordingly...any ideas?
That sounds like things are working exactly as they should. What do you want to have happen? And why do you need the separate databases?
Well, ideally, I would like my siloed table/DB to be a mirror image of my main table - display all of the data from the layout in the main table so an individual that was only working in the siloed DB would see just this information and be able to add or delete records and have this reflected in the main table.
The idea is I want to have several siloed DB's that only some people are going to work on while also having a main DB that captures all of the info from the siloed DB's that another large group would work from. Does this make sense?
Apologies, If I'd read your earlier post more carefully, I wouldn't have posted the first sentence. I missed "none of the data can be viewed".
However, now that I have a clearer picture of what you want to do, I'd suggest a vastly simpler approach that achieves the result you want. Read up on Accounts & Privileges in the help system. You can also search this forum for threads on "Locking a record" (Use the Advanced search link above). To build some background info and see some examples.
What you can do is create a single database file and use accounts and privileges to control what data is accessible to them. You can control what layouts are visible, what records may be viewed and/or edited etc. and you can do it all with one database file to make your job much much easier.
I've thought about that approach but would like to keep all of the data seperated in individual files so if something does happen to the main user file all of my siloed data will still be intact.
Any thoughts on why I can't see the data in my siloed DB? The layouts for both tables are identical and as I said it appears the records are coming across in the siloed DB based on the record counter - just none of the data is viewable. I feel like at this point I am just missing something simple, like needing to merely activate something I don't have turned on.
What do you see in layout mode?
Perhaps the fields on your layout are referring to the wrong table occurrence.
You could try creating a brand new layout and point it at your table occurrence in Manage | Database that refers to your external file.
When it comes to data security, keep in mind that you can host your files from Filemaker Server and build in regular automatic backups to secure your data.
You are looking at creating a synchronized system with one master file being fed by multiple siloed files. This can be done but it is complex and, according to your posts, is not necessary.
As Phil said, a single file with correct priviledges would take care of your all your data needs. A good backup regimen would take care of the disaster scenario you envision.
Backups are the real answer to disaster recovery. FileMaker Server is much better suited for the backup task than FileMaker Pro. Mac OS X's Time Machine or a similar backup utility in either Mac OS X or Windows adds an extra layer of backup safety.