I've been looking at using Bento for iPhone / iPad on a few projects where data will be logged in the field and then synced with a main database held on a Mac. My worry with this system though is that if there is a problem when the Bento database syncs with the Mac and the databse gets corrupted, there may be a complete loss of data. Ideally I'd like to, for instance, email the data from the iPhone / iPad before the data is synced so that even if the databse is lost, at least we have the data and can manually enter the data onto the main databse on the Mac. I have not yet however found out any way of getting the Bento data off the iPhone apart from syncing with a Mac. Does anyone know of any other fix for this?
Bento has no capabilities to sync over the network, no printing (you can print documents attached/embedded in a record but not the actual record itself). It was designed to be totally simple. That makes it the wrong tool for protect data to the extent of allowing backups or export/import like you ask.
The API are there to use MobileMe syncing on both the mac and the iOS - but the engineering wasn't done to make that work in the Bento universe. There are many solutions that will work at greater (but still affordable) cost, though.
In your case Filemaker Go connecting to a database that is served with FileMaker Pro will ensure your field data is always syncing to and from a central server as long as the network allows connectivity.
Here is a nice summary of how Bento and Filemaker Go compare. Bento has been very reliable for me and I haven't heard of anyone losing data, but user error or a lost phone before you return to sync will clearly cause lost data.
There are many note taking apps that sync off device to a server (Simplenote is the one I use) and even more GTD / Task Management type apps (like Things or Todolicious or the big kahuna OmniFocus) that you might be able to leverage to avoid losing data via sync services.
In the end - FileMaker Go + Pro is orders of magnitude cheaper than custom app developmen,t not to mention ridiculously faster to implement. If the cost of losing one set of data exceeds easily calculated FileMaker deployment costs, then your decision is trivial to make. Don't forget to estimate the cost of going back to recreate the data.