Mirrorsync filemaker cloud1/28/2024 When running in sync mode, LCFM Native will run and allow continued use of an app regardless of whether there is a connection to the hosting server – indeed it works the same as if you were running the solution locally all the time. LCFM Native is different – it is designed to be able to offer you the best of both worlds. The reason it requires this is that FileMaker uses what is called a ‘pessimistic locking model’ – where in order for a client to modify the database in any way it needs to tell the host about the change before it happens so that no other (currently connected) clients can make conflicting modifications and this lock remains (and continues to affect all other clients) until the changes are committed and sent to the server. because the local network fails, or the internet fails briefly, or the devices wifi or cellular connection drops) then the solution cannot continue to function at all until the connection re-appears and a new connection can be made. When operating in the hosted mode FileMaker requires that there is always a connection to the machine hosting the solution – if the connection disappears (e.g. Why the Sample Assets solution by default is Non-SyncableįileMaker is designed and built to either run entirely locally by a single user or by multiple users connecting to a solution either hosted in FMProAdv or in FMServer. We first explain why it is not syncable in the next section then show how to make it syncable in the last section. One important thing to note about the history table is that records in it are ‘create only’ – there is no way (through using the solution alone) for a record in the history table to be modified after it has been committed.Īs it stands the (Sample) Assets solution is not syncable with LCFM Native – fortunately though, it is easy to make it so! This arrangement of tables and relationships means that each record in assets essentially ‘owns’ its own set of history records. The join is set to allow deletion when records are deleted from assets. There is an equals join relationship between the Assets and History tables via the ASSET ID MATCH FIELD in both tables which causes it to be a one-to-many relationship. The History table has a foreign key field ASSET ID MATCH FIELD. The latter two fields will get changed to the current logged in user name and current timestamp whenever a change is committed to the record. Additionally, it has an auto-enter on modify modification name field (Modified by User) and an auto-enter on modify modification timestamp field (Modified Timestamp). The field is set to be auto-enter on create serial with increment 1 – meaning each newly created record has it set to an integer one higher than the previously created record. The Assets table has a primary key field ASSET ID MATCH FIELD of type number. The solution consists of two tables, Assets and History. The last modification time and modification user of each asset is tracked. Assets can be checked-in, checked-out and a review of the condition of the asset applied – the latter all being recorded in a history. The solution allows tracking of assets within an organization of various types, with photos, serial number and including calculation of depreciation values. The (Sample) Assets solution is one provided with FileMaker 17 as an example of a complete, albeit relatively simple, solution. This is supported in Beta 3 so you can try it out today. However LCFM Native comes with the ability for your app to run offline and for that, you might need to make minor changes to your solution to make it work. If you don’t want to sync, you don’t need to do this, your app will work without changes. ![]() LCFM Native allows you to sync your data from your Android app back to your FileMaker database and vice versa. ![]() Syncing your FileMaker solution – Overview Video: Setting up the Sample Assets FileMaker solution for sync
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |