Thank you for your post.
Before others chime in with their experience, here is some reading material you may (or may not) find useful:
Knowledge Base Article #7720 - "Database syncing - an overview of approaches"
FileMaker Sync Guide - Best practices for building your own system
Outside of building your own syncing mechanism, there are at least two third-party utilities that will sync FileMaker Go with FileMaker Pro.
MirrorSync by 360Works
You might also take a look at whether a data separation model approach to the design of your database might reduce the need for synching when you are ready to deliver a new version: Convert to Seperation Model
Thanks for all the answers. It was some good reading. But I still feel like there is a simpler way to just put the data he has entered into my current database. I'm probably wrong. Most of those solutions seem to have the assumption that the database the FMGo user uses is "finished" to some extent and how to keep it along with the server in sync. I only want to add the data from the FMGo to my latest FMPro database. After that I'll just give him the latest file with the data he entered.
Those solutions may provide this answer, but I couldn't clearly distinguish it.
Thanks to any further help with my concern!
"Phil knows best" is the motto I always follow. Some other thoughts.
1. What if the data he sends you, now clashes with your updated version (fields, validations, etc.).
2. You could have him drop the file into a shared dropbox account. Then pull it up and import the data into your database. but it seems to me this would have to happen quickly, as you need his data to put into the database, check it, while he waits for you to send it back to him so he can continue working.
"Phil knows best" is the motto I always follow.
But as TSGal pointed out in the links shown above, there are ways to use import records to import the data from one copy of the database file into another. This is a process that can be scripted.
Someone also has mentioned a third party app: http://www.psfe.com/fmfilemanageronthego/
that is supposed to be able to automate this process for you. But I have not actually tried to use this tool myself.
a bit of a scary attitude as I am far from perfect.
Phil I read practically every post in 'Pro & Go". You pretty much respond to them all. You've never led anyone (of course myself included) astray.
I'm not scared :)
Actually, I have lead folks "astray a number of times and there are times when others have taught me new methods from their posts when they chimed in with a correction or a much better solution...
Your use of the word 'sync' has caused everyone to overlook the simplest idea of all: import the data from his db to yours.
Open the file on your computer and use the import step to locate his file (you can get a copy onto your hd) and import each table's data into your empty tables.
This can be scripted and you can also send him the new empty clone so he can import his data from the prior file into the newer file.
Synching is not appropriate for the your current methodology. Import is.
Importing is an old fashioned idea and is far simpler than trying to use cumbersome and buggy third part applications for syncing. And cheaper.
Why do you want your friends data? You can create dummy data and records for design purposes and prevent information conflicts and privacy concerns.
2nd cup of coffee:
Establish these rules:
You never change the definition of a field or its name.
Your links remain intact but you can add new tables and new links.
You keep the last version so you can establish the proper import routine.
Your new file will be used by your friend to import the data from his old file.
The import scripts:
Your friend downloads the file to his computer and sets the name of that file to one you want to use.
You create on your computer a TO for this named file. It will work on his computer.
Your script imports data from each table in this named file using something like:
Go to layout bbb of table xxxx
Import from file yyyy using table xxxx using matching field names
go to layout ccc
You can test this using dummy data in the file to be imported. All records should match in both files.
By importing all tables in the above script you will fill in the related tables, etc.
One problem is the serial number fields and you may have to work on a routine to reset the next value and as this gets complex, I won't try to explain it. Filemaker's internal record count may also go astray.
Import records is one of the methods documented in the sync guides TSGal posted.
One problem is the serial number fields
Instead of serial number fields use Get (UUID) in an auto-enter calculation and you will not have any serial numbers to reset.