This is a common question in this forum so you may want to do a search for other responses.
The syncing of new records is not a problem. Instead of using a simple serial number for you prime record key you use a custom function that create a UUID. These functions create an ID that will be unique for several billion records. Then you import your new records skipping any that already exist.
The problem comes when you change data in an existing record, say you and another user change data on the same record, a phone number. When the db goes to sync how is FM to know which is really the "best" piece of data to retain?
The iPhone's native message app will give you an idea of the problem and a "sort of" solution. If during a sync with iTunes it detects a data change on a message, it shows you a copy of both messages and will ask the user which copy to keep or let you skip the decision and get back to it later).
There are commercial solutions, WorldSync, is one; but I don't know if and how it would work in this scenario.
My bad, the iPhone app to look at is Notes, not Messages. Notes sync in iTunes to the Mail app on your computer.
If you have the 3G iPads, another solution would be to host your DB on a commercial FMP hosting service. This way, the iPad users would have access anywhere there is a cell signal and all users (including the tower at the office) are using the same DB at the same time; no "synchs" required :) This is the setup I am using at the moment and all is working just fine.
Unfortunately, we only have the wifi versions. Got them cheap when ipad 2 came out. Also didn't want to pay the 3g data prices.
Excuse my ignorance with this, I'm new to filemaker, picked it up when I saw the ipad app.
I'm thinking of creating 2 tables, with the same data, one for me, one for the other guy in my dept, then trying to do a sync between the 2 tables. Would that work?
Not really. A FileMaker file can be compromised of as many tables as are necessary to get the job done effectively. You need to be looking at how to create a file with the tables and fields and relationships, then you can just duplicate the file and then work on sync'ing it.
Give us a little more information on what it is you trying to accomplish and we might be able provide more options. Also what data are you collecting and how often will existing records be changed, new records created, etc. The hard part of sync'ing is updating records that have changed since creation, if you are just creating new records FileMaker can do that out the box.
The db I have created is an inventory listing of the computers we have at my office. About 250. Information collected primarily consists of Computer Name, User name, Floor (we have 4) model, Tag, ram amount. THen when I need to perform an update or install something, I create a check box or a yes/no pulldown so that I may check off the computers where the task has been completed.
Really only do the install/update once or twice a year tho. But all records will need to be updatable, yes.
Like I previously said, I could just merge the data from 2 seperate tables, that's not a big deal. I would primarily be looking for the change if a record hasn't been checked off on one table, has it on the other, and if yes, to make the change. Woudn't really be checking for the reverse.
Here are my ideas on how you might proceed.
Starting from the premise that the hardest part of syncing a db is when the a previously created record has been changed since the last sync, perhaps even on both iPads we seek to limit or eliminate this from occurring.
Starting from a table for the base computer records (the parent table), this will contain only the data that seldom changes, manufacturer, serial number, etc. A second table (the child table) for everything that can In the or will probably change, the user, the location, software installed, ram, OS, etc. Each table will have a UUID for primary keys (there are several available as custom functions on Brian Dunnings site, I like Ray Cologen's at Nightwing) the two tables will be related by the parent key, allow record creation in the child table. You could create a series of tables for every possible event that you could have with regard to each computer, however, I would only have one child table and filter the relationship for the more common activities with the key fields and a label, ie, RAM, OS, User, Location. This way you can also have a single portal that would show all of the activity for each computer and you could have different drop downs on each portal, but they would be addressing the same field. Set up a record lock on the child records to never allow them to be altered after a sync. All records in both files have a field for last modified timestamp.
For syncing of the parent table I would then create an exact duplicate of the parent table as a shadow table, each time you sync, import all of the parent files into the shadow file and script a comparison for the an equal UUID and an unequal modTs. Create a layout that allows you to look at all fields from both the parent and shadow tables, If you get a hit you can compare the data and decide which one to keep. In the the child table, since each action will be a separate record and can't be changed after the fact, you can import all (or just the newest) of these records directly into the child table.
After each sync replace the Go files on each iPad with a copy of the synced file. I would suggest keeping the originals of everything, just in case.
I hope this helps, if you have any questions fire away.