Changing the table occurrence of a sync layout

[sfpx]

I would like to change the table occurrence of a sync layout.

1.The layout would remain the same, same fields (but from a different occurrence).

2.The filter would return the same records just faster and on a different table occurrence.

Ex:

Sync layout: TestLayout

Original table occurrence: Test

New table occurrence : SyncTest ( occurrence of test)

What would happen to the users who haven't got the new version of the database and sync?

Would that cause problems because they are expecting records from test and get records from SyncTest or would that work just fine because they actually get the expected fields ?

 

 

Edited September 20, 2018 by sfpx

[Jesse Barnum]

This is not something I've ever tested or tried, so I don't know the answer here. You can certainly just give it a shot to see what happens. Best case scenario, it works fine for existing offline files. Worst case scenario, you would need to run through the whole configuration, re-paste script steps, reset sync data, distribute new offline copies.

[sfpx]

1 hour ago, Jesse Barnum said:

This is not something I've ever tested or tried, so I don't know the answer here. You can certainly just give it a shot to see what happens. Best case scenario, it works fine for existing offline files. Worst case scenario, you would need to run through the whole configuration, re-paste script steps, reset sync data, distribute new offline copies.

Not really willing to do that

I will eventually test it on a test database if I got some spare time.

Now , it's a bit off topic but I found out that a relation sort can greatly impact the filter speed if your filter is looking for a related field even if if it's not the related table that is sorted but the sync table itself.

 It's really a strange filemaker behavior.

Example:

TableA-TableB

TableB is sorted in the relation

You are on the TableB layout and you perform a find on TableA.

The sort will slow down the operation even if it's not TableA that is sorted but TableB.

Pretty annoying stuff but it's good to know I guess.

 

Edited September 20, 2018 by sfpx

[Jesse Barnum]

I did not know that about the sorting slowdown.  I typically do relational sorting in portals, not the relationship graph - would that be a feasible solution?