Synchronizaton Log Redux

[nlk10010]

I just realized I asked this exact question about 5 years ago, but was hoping Alpha has provided some additional information about how the synchronization log feature works.

I have a disconnected mobile app that started to leave duplicate records on the server when it synched. I turned on the synch log feature and most of them stopped, but there are still a few duplicates being created every once in a while. I'd therefore like to know exactly how this log works so I can track down the cause of the problem (it might be something my app is doing). The best I can find is exactly the same information that appeared when I asked the question the last time. Alpha uses the log to prevent duplicates and it somehow involves the client app firing an additional callback after it gets a response from the server. I tried to figure out how this works but I can't seem to do it: For example, suppose the client app sends a new record to the server, to be added to the database. The record of course has no primary key (we use AI Numeric PKs). The server adds it and then adds a record to the log, including the new AI primary key. The server also sends a message back to the client, but if the client has in the meantime lost its connection it never receives that message. So no additional callback is fired and the server knows this. But now suppose the client adds another record and sends another package to the server. In particular, the server receives two records with blank primary keys, one the original that the server has already added and the other a completely new one. How does the server use the log to figure out WHICH record was the one it previously added to the database?

The above is of course a long way of asking if anyone has any idea how this synch log table actually works (i.e. if any new information has been released). I can't find anything new via Google search or search of these Boards.

As an aside, I HAVE checked the "Clear log table...." option in Project Properties but find (as best I can determine) that Alpha does not clear it, it just keeps getting larger. Of course that's of secondary concern.

Thanks in advance for any (new) ideas.



Norman

[RustyB]

I would un-check "Clear log table". Alpha states this gives you a little added protection against duplicate updates an inserts. Perhaps it is possible that the server sends a message to the client that the sync was successful and then clears the log table, but the client doesn't receive the message to tries to sync the same records again. Since they are missing from the sync log table you get duplicates. You can handle the sync log table growing too big by writing a procedure in your database to clear out older records.

[nlk10010]

Well, as I say, even though "Clear log table" is checked Alpha does NOT appear to be doing that. It seems no entries are ever erased as the table keeps growing bigger.

I realize nothing is perfect and the log table does seem to help somewhat; do you recall offhand where you read (or heard) that Alpha recommends unchecking this option, that it will give a more protection against duplicate updates? I don't remember seeing anything like that. Regardless, I still don't see how a log table would protect against duplicate inserts. There seems no way Alpha can tell by looking at the log table and a newly submitted record if that specific record was already added (at least that's my assessment).

Thanks for your post, I'd love to read something about the logic behind this technique.

[RustyB]

When you go into your list, on the Detail View tab, and you click on the property "Clear sync log table after successful sync". You'll notice the hep at the bottom of the page says "For added protection against duplicate updates and inserts you can uncheck this property."

In my log table it inserts a Primary Key. My understanding has always been if the client attempts to insert that record again for the same RowGUID, it will not insert it because the log indicates that the insert has already happened. If the client then updates the record, it will get a new RowGUID and therefore be able to be updated on the server. These are just my assumptions however. I never really looked into it too deeply.

[nlk10010]

Ahh, the onscreen help. Thanks, Alpha has so much of this sort of stuff stuck in all different parts of the UI I'm sure I miss at least half of it. That's one of the things I really like about developing with it.

You bring up the Row GUID, which is something I see in the log but don't know anything about. How does using it differ from using the primary key? If it's generated on the client THEN I can see Alpha being able to detect a duplicate add, if on the server I still don't see it. Regardless, I will search for Row GUID and see what I can come up with.

BTW, I just spied a YT video on synchronization, maybe that holds the "key".

[RustyB]

Yes Row GUID is generated on the client. For troubleshooting purposes you can add it to your list. Just add a new Virtual Javascript field to the list, and then use code similar to the following

if(data.hasOwnProperty('*rowGUID')){
return data['*rowGUID'];
}

My guess is that you need the rowGUID for two reasons. One is that you likely have multiple lists in your app synching to multiple tables in your database. Since the log makes no mention of table name, a Primary Key alone would not be helpful since different tables might use the same Primary Key. Secondly, the sync log also has to handle updates. What if you insert a record, the primary key gets added to the log, and then you update the record on the client. The only way the for the log to know that the client has updated the record and it is not a duplicate of the first insert is for the client to assign a new row GUID after every update.

Well hope this has been helpful to you. Good luck.

[nlk10010]

It has. Thanks.