You could solve this, and a lot of other potential problems, by sharing the file and everyone logging in to it as guests.
If sharing the file is not possible, take a look at using Get ( UUID ) in an auto-enter calculation as a way to enter an ID string (It's text) that will be unique across all your users.
Sharing is not an option.... We are a group of vets, who work in remote locations (often without a mobile signal, much less 3/4G!). This way we all get a chance to input data which can be pushed back to 'base' once we get home, rather than writing it by hand in a book and transcribing it onto the computer when we get back to base (which can sometimes be a few days!)
I will take a look at Get scenario using the UUID - I guess there is a way of setting the import settings just using the UUID then!?!
I have a week to prove this the the group that it can work.. Thanks for the input, it is greatly appreciated.
We are right in the middle of a project to do just what you are suggesting.
Thanks for the good luck wish!
I found a previous post on the forums : http://forums.filemaker.com/posts/09acb1dc6a
This could work for us.... only problem s I am using FMP12 and the instructions are for FMP11 - I have it working, but it will only re-import exisiting entries, rather than excluding them from the improt and allowing new entries to go through.
I have attached a few screen shots... have I got a setting wrong?
p.s. if I get this to work I will gladly share the db if its any help!
If all you are ever going to do is send new records from the iPad back to the 'Central File' then it is actually pretty easy, in any version of FM. The temporary non-uniqueness of the IDs is relatively trivial. The problems start to arise when you are raising locally both parent and child records. That's a little more complex to sent back. Then - and I will almost guarantee you will evolve to want this - you will want to genuinely 'exchange' data. In other words one vet saw the beast last night at 11:00pm, reported, added drugs, made suggestions. Sent back to the Central File before going to bed. You call out to the animal the next morning... and you will want to have local access to the diagnosis, drugs, stats of last night's visit.
That's where the fun starts...
Phil's previous warning that synchronisiation should not be taken lightly should... not be taken lightly.
By the way there is a plug-in available for FM12 which is designed to do the synchronisation for you. But no synchronisation is easy, and you really need to explore ALL of your administrative options before going with one solution. (What happens if a vet adds a drug locally, on-site. And before, during, or after synchronising, someone back at base adds the other drug that has just come into stock? The vet's list is 4 drugs, the central list is 4 drugs, and then they synchronise. To 5 drugs? Or 4? Which 4? And note the 'while synchronsing' I dropped in there. I would suggest you need to look at locking the whole file (almost) while anyone is synchronsing. That is not easy to accomplish without making it administratively handicapped.)
If all you are ever going to do is send new records from the iPad back to the 'Central File' then it is actually pretty easy, in any version of FM.
This is all we currently have to do. I should briefly explain - our practiuce is starting to come out of the dark ages wrt any technology. The concept of using ipads for remote note taking was almost a revelation to some members of the practice a few months ago.
Therefore we only need to send info 1 way - once back at 'base' it is manually put onto our current practice computer system (which is that old its still running a Microsoft access DB). Until the pratice updates their system we are happy for one way transfer. No syncing back required.... this is a future project (which I will continue to work on in the coming months)
Thanks for all your help / input.
Running a central FM file updated with regular remote access from iPads is perfectly within the capabilities of Filemaker.
I just noticed that you said they were e-mailing their copy back to base. They don't have to do that; the update can be scripted to upload directly to the central file from wherever they have the internet connection they are using to send the e-mail.