Joshua Willing Halpern

My friend pointed me to this thread asking how I might solve this, and once I saw @comment's solution I just laughed. Brilliant idea.

Right, i'm thinking in terms of if you "do everything right", rather than ad hoc record creation by a user. I.e. go to layout, show all records then start creating records. That would prevent the omit/found set issues that could arise, but I believe we still might get duplicates if two users created a record n "at the same time". Disaster could probably be averted with unique field validation, but it's just not worth the hassle. Rather auto-enter serial is the way to go because the source of truth about the next "record number" isn't tied session/context/found set. That totally works as long as you don't need to sort/filter the displayed results. For that we need a stored recordNumber field. But to bring it back home, I think auto-enter makes record creation safe in multi-user environments, when used with some simple precautions like always showing Virtual List results as a found set or in a portal so the user doesn't see extra empty rows magically appearing at the end of their report.

I can't think of a multi-user scenario where it's safe to delete Virtual List records. But creating records should be fine if you use Auto-enter serial number to set the recordNumber field (like @LaRetta said). I feel like it would be unsafe to use auto-enter calculation of `Get (recordnumber)` because if User A and User B are creating records simultaneously and they both create a record before either one commits, you might get a duplicate value in the recordNumber field. Is that right?

If you set es last push and last pull time stamps correctly then it should jump over those two sections super quickly, So confirm that. Is is it getting stuck on the “sync check” part?

Nice!

Hey, I'm going from memory here, but to avoid an initial sync, before you deploy the local copy, set ES_Last_Push_UTC_Time, and ES_Last_Pull_UTC_Time to the current UTC using Get ( CurrentTimeUTCMilliseconds ). That will trick the local file into thinking it just synced and it will consider itself up to date (until a record changes on the server or locally). I think there is also a "last full sync" field somewhere that you may want to set to the current timestamp. But that one should automatically update after your next sync.

Barbara! Looks great, and excellent refinements. I want to implement something like this in a future version as well. Thanks for sharing your code.

Let us know what you come up with! j

Barbara, you're totally right. Just to be clear, updating the ES_UTC on the server should always prevent that problem of records not being pulled, barring any simultaneous sync snafus. However This brings up another issue: e.g. If two users edit the same record, User A does first, and User B does second. If User A syncs first, then the record on the server will update with a new later timestamp and when User B goes to sync, she will end up pulling the data as edited by User A even though she ( User B ) was the last to edit the record :/. Just spitballing, but I believe this could be solved with a second timestamp field. Use ES_UTC to determine if the record should be examined at all during a pull, and a new ES_UTC_ACTUAL that only ever reflects actual user edit timestamps and is used for conflict resolution. Cheers, J

Here's my understanding. The $script_override is used during a pull to keep ES_UTC and ES_Device_ID from auto-entering on the local file, so that's fine. And ES_Device_ID should also not auto-enter on the server and should be set the same as that in the pushed record. Tim originally scripted it to do that by sneaking this in in the middle of 'Process Payload from Client': The calc shows that instead of letting ES_Device_ID update by itself with the server's id, it uses $client_persistent_id, which comes from the script parameter. In summation: $script override prevents auto-enter while the field is manually written. All good so far. But i don't think he actually addressed the issue you raised, where a lazy syncer might not sync their device for months and other users will therefore not pull his new/updated record. We need to allow the server to auto-enter in the ES_UTC field. I did this by splitting the variable into $script_override for the ES_Device_ID field and $time_override for the ES_UTC field. That way you can independently control when each field's auto-enter calc is turned off, which is what you need during Process Payload from Client. Round tripping will still be prevented because ES_Device_ID still matches but other users will be able to pull the data because the ES_UTC field is now later than their last sync. Once broken apart, make sure both are set to 1 during a pull and only $script_override is set during "Process Payload from Client". It's been a while so I hope my understanding is correct and that that helps. J

I'd say Mirrorsync is the quickest sync tool I've come across. But Easysync can be a great solution--how many records will be in your sync payloads, and across how many tables?

Hey, try adding this line (including the quotation marks) at the end of your SQL statement: "AND ( \"_kf_uuid_companys\" = ? )" Please note the \" around the field name--You'll need these since your field starts with _. Then include $additional_settings as the argument in your ExecuteSQL calculation like so (See attached image). Alternatively you can embed the variable right in the SQL text: "AND ( \"_kf_uuid_companys\" = '" & $additional_settings & "' )" P.S. This doesn't matter at all, but I believe it's spelled companies.

Hey, I want to create invoices with three different types of line items, 1) rental items, 2) people for hire, and 3) rental add-ons. Should I place all three in a single products table with extra child tables for each's type-specific info or should I create three different foreign keys in the line items table and create relationships to all three tables?

Did you determine the cause?

Glad it's working for you! You may want to read tmr_slh's comment a couple entries up and verify that this modification works on all platforms you need it for. If not his suggestions look promising though I haven't tried them and I don't know that they all have the same linear complexity. Cheers.