They are handled a bit differently for sync (see this example), but are fields nonetheless. Signatures are stored in container fields. If it sees new edits from the field, it will process the edits and update the appropriate fields throughout the system. In the meantime, FileMaker Server has a listening routine that checks for new uploads from the field every minute. The MobileEditLogs just sit there until connection is restored. If there is no connection, nothing happens. If there’s a connection available, it immediately sends the edits to server. This is the data cache for syncing.Īt the end of an edit cycle, the sync system checks for a connection to server. It doesn’t matter if there’s a connection to server or not, these edit logs are created. As the drivers edit the forms, entries are created in a table called MobileEditLog. The basic idea is this: Forms and related data are downloaded to the iPad. So the FileMaker Go solution uses API-based sync routines that Jonathan and I developed together to send and receive data to the server. On the delivery routes, cell reception can be quite unreliable, especially since much of the delivery work takes place inside of old New York City apartment buildings and warehouses. Within the local area network (LAN), it is accessed via FileMaker Pro on desktop, and FileMaker Go on iPad. We have a two-file freight delivery solution (separation model) that is shared via Claris FileMaker Server 19 and is hosted on a Windows Server Instance from Amazon Web Services.
0 Comments
Leave a Reply. |